56、策略模式(上)
策略模式在实际的项目开发中也比较常用,最常见的应用场景是,利用它来避免冗长的 if-else 或 switch 分支判断
不过它的作用还不止如此,它也可以像模板模式那样,提供框架的扩展点等等
1、策略模式的原理与实现
策略模式,英文全称是 Strategy Design Pattern,在 GoF 的《设计模式》一书中,它是这样定义的
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
翻译成中文就是:定义一族算法类,将每个算法分别封装起来,让它们可以互相替换,策略模式可以使算法的变化独立于使用它们的客户端(这里的客户端代指使用算法的代码)
工厂模式是解耦对象的创建和使用,观察者模式是解耦观察者和被观察者
策略模式跟两者类似,也能起到解耦的作用,不过它解耦的是策略的定义、创建、使用这三部分
1.1、策略的定义
策略类的定义比较简单,包含一个策略接口和一组实现这个接口的策略类
因为所有的策略类都实现相同的接口,所以客户端代码基于接口而非实现编程,可以灵活地替换不同的策略
public interface Strategy { void algorithmInterface(); } public class ConcreteStrategyA implements Strategy { @Override public void algorithmInterface() { // 具体的算法 ... } } public class ConcreteStrategyB implements Strategy { @Override public void algorithmInterface() { // 具体的算法 ... } }
1.2、策略的创建
因为策略模式会包含一组策略,在使用它们的时候,一般会通过类型(type)来判断创建哪个策略来使用
为了封装创建逻辑,我们需要对客户端代码屏蔽创建细节,我们可以把根据 type 创建策略的逻辑抽离出来,放到工厂类中
/** * 策略的创建: 如果策略类是无状态的,不包含成员变量,这样的策略对象是可以被共享使用的 */ public class StrategyFactory { private static final Map<String, Strategy> strategies = new HashMap<>(); static { strategies.put("A", new ConcreteStrategyA()); strategies.put("B", new ConcreteStrategyB()); } public static Strategy getStrategy(String type) { if (type == null || type.isEmpty()) { throw new IllegalArgumentException("type should not be empty."); } return strategies.get(type); } }
一般来讲,如果策略类是无状态的,不包含成员变量,只是纯粹的算法实现
这样的策略对象是可以被共享使用的,不需要在每次调用 getStrategy() 的时候,都创建一个新的策略对象
针对这种情况,我们可以使用上面这种工厂类的实现方式,事先创建好每个策略对象,缓存到工厂类中,用的时候直接返回
如果策略类是有状态的,根据业务场景的需要
我们希望每次从工厂方法中,获得的都是新创建的策略对象,而不是缓存好可共享的策略对象,那我们就需要按照如下方式来实现策略工厂类
/** * 策略的创建: 如果策略类是有状态的,包含成员变量,这样的策略对象无法共享使用 */ public class StrategyFactory { public static Strategy getStrategy(String type) { if (type == null || type.isEmpty()) { throw new IllegalArgumentException("type should not be empty."); } if (type.equals("A")) { return new ConcreteStrategyA(); } else if (type.equals("B")) { return new ConcreteStrategyB(); } return null; } }
1.3、策略的使用
策略模式包含一组可选策略,客户端代码一般如何确定使用哪个策略呢:最常见的是运行时动态确定使用哪种策略,这也是策略模式最典型的应用场景
这里的 "运行时动态" 指的是:我们事先并不知道会使用哪个策略,而是在程序运行期间,根据配置、用户输入、计算结果等这些不确定因素,动态决定使用哪种策略
public class User { private Strategy strategy; public User(Strategy strategy) { this.strategy = strategy; } }
/** * 运行时动态确定, 根据配置文件的配置决定使用哪种策略 */ public class Application1 { public static void main(String[] args) throws Exception { Properties props = new Properties(); props.load(new FileInputStream("./config.properties")); String type = props.getProperty("strategy_type"); Strategy strategy = StrategyFactory1.getStrategy(type); User user = new User(strategy); // ... } } /** * 非运行时动态确定, 在代码中指定使用哪种策略 */ public class Application2 { public static void main(String[] args) { Strategy strategy = new ConcreteStrategyA(); User user = new User(strategy); // ... } }
从上面的代码中我们也可以看出
"非运行时动态确定" 也就是第二个 Application 中的使用方式,并不能发挥策略模式的优势
在这种应用场景下,策略模式实际上退化成了 "面向对象的多态特性" 或 "基于接口而非实现编程原则"
2、如何利用策略模式避免分支判断
能够移除分支判断逻辑的模式不仅仅有策略模式,后面我们要讲的状态模式也可以,对于使用哪种模式,具体还要看应用场景来定
策略模式适用于根据不同类型待动态,决定使用哪种策略这样一种应用场景
2.1、示例
我们先通过一个例子来看下,if-else 或 switch-case 分支判断逻辑是如何产生的,具体的代码如下所示
在这个例子中,我们没有使用策略模式,而是将策略的定义、创建、使用直接耦合在一起
/** * 订单 */ public class Order { private OrderType orderType; public OrderType getType() { return this.orderType; } }
/** * 订单类型 */ public enum OrderType { NORMAL, GROUPON, PROMOTION }
public class OrderService { public double discount(Order order) { double discount = 0.0; OrderType type = order.getType(); if (type.equals(OrderType.NORMAL)) { // 普通订单 // 省略折扣计算算法代码 ... } else if (type.equals(OrderType.GROUPON)) { // 团购订单 // 省略折扣计算算法代码 ... } else if (type.equals(OrderType.PROMOTION)) { // 促销订单 // 省略折扣计算算法代码 ... } return discount; } }
2.2、优化
如何来移除掉分支判断逻辑呢,那策略模式就派上用场了
我们使用策略模式对上面的代码重构,将不同类型订单的打折策略设计成策略类,并由工厂类来负责创建策略对象
public interface DiscountStrategy { double calDiscount(Order order); } // 正常折扣策略 public class NormalDiscountStrategy implements DiscountStrategy { @Override public double calDiscount(Order order) { return 0; } } // 促销折扣策略 public class PromotionDiscountStrategy implements DiscountStrategy { @Override public double calDiscount(Order order) { return 0; } } // 团购折扣策略 public class GrouponDiscountStrategy implements DiscountStrategy { @Override public double calDiscount(Order order) { return 0; } }
/** * 策略的创建, 折扣策略类不包含成员变量, 可以缓存起来 */ public class DiscountStrategyFactory { private static final Map<OrderType, DiscountStrategy> strategies = new HashMap<>(); static { strategies.put(OrderType.NORMAL, new NormalDiscountStrategy()); strategies.put(OrderType.GROUPON, new GrouponDiscountStrategy()); strategies.put(OrderType.PROMOTION, new PromotionDiscountStrategy()); } public static DiscountStrategy getDiscountStrategy(OrderType type) { return strategies.get(type); } }
public class OrderService { public double discount(Order order) { OrderType type = order.getType(); DiscountStrategy discountStrategy = DiscountStrategyFactory.getDiscountStrategy(type); return discountStrategy.calDiscount(order); } }
2.3、更多
重构之后的代码就没有了 if-else 分支判断语句了,这得益于策略工厂类
在工厂类中,我们用 Map 来缓存策略,根据 type 直接从 Map 中获取对应的策略,从而避免 if-else 分支判断逻辑
等后面讲到使用状态模式来避免分支判断逻辑的时候,你会发现它们使用的是同样的套路
本质上都是借助 "查表法",根据 type 查表(代码中的 strategies 就是表)替代根据 type 分支判断
但是如果业务场景需要每次都创建不同的策略对象,我们就要用另外一种工厂类的实现方式了,具体的代码如下所示
public class DiscountStrategyFactory { public static DiscountStrategy getDiscountStrategy(OrderType type) { if (type == null) { throw new IllegalArgumentException("Type should not be null."); } if (type.equals(OrderType.NORMAL)) { return new NormalDiscountStrategy(); } else if (type.equals(OrderType.GROUPON)) { return new GrouponDiscountStrategy(); } else if (type.equals(OrderType.PROMOTION)) { return new PromotionDiscountStrategy(); } return null; } }
这种实现方式相当于把原来的 if-else 分支逻辑,从 OrderService 类中转移到了工厂类中,实际上并没有真正将它移除
3、图示
本文来自博客园,作者:lidongdongdong~,转载请注明原文链接:https://www.cnblogs.com/lidong422339/p/17522847.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步