美好的一天

算是读书笔记吧 极客时间--设计模式之美 什么是策略模式 Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码） 策略模式对策略的定义、创建、使用三部分进行了解耦 策略模式的作用 策略模式解决的问题 策略模式表面上看是为了避免 if-else 分支判断逻辑，但更深层次上，还是为了解耦以及控制代码复杂度 比如在出门旅游时：路线、交通工具的类型、天数、舱位等级、餐饮、住宿等等。 每个节点在执行时，都需要根据预算Type进行不同的操作，从而引起大量的if-else判断。增加一个策略，修改一个策略，都有可能牵一发而动全身。需要对所有状态进行回测。 public void departure () { Int money = 100; String destination = getDestination(money); //获取目的地 String vehicles = getVehicles(money); //获取交通工具 天数、舱位等级、餐饮、住宿等等..... } private String getDestination (Int money) { if (num < 1000) { return "1000块能去得起的地方"; } else if (num < 5000) { return "5000块能去得起的地方"; } else if (num < 10000) { return "10000块能去得起的地方"; } else if (num < 20000) { return "20000块能去得起的地方"; } else if (num < 40000) { return "40000块能去得起的地方"; } else if (num < 80000) { return "80000块能去得起的地方"; } else ... } private String getVehicles (Int money) { if (num < 1000) { return "骑车"; } else if (num < 5000) { return "火车"; } else if (num < 10000) { return "火车"; } else if (num < 20000) { return "飞机"; } else if (num < 40000) { return "飞机"; } else if (num < 80000) { return "飞机"; } else ... } ...后面还有一大堆相关的方法需要判断 整个业务如图所示，所有的判断都耦合在业务流程内部，牵一发而动全身 使用策略模式 我们可以将某一条件（Type）下的逻辑，聚合封装到具体的策略类中 public class departureStrategy1000 implements Strategy { //1000块的旅行策略 @Override public void getDestination() { return "1000块能去得起的地方"; } public void getVehicles() { return "骑车"; } 天数、舱位等级、餐饮、住宿等等..... } 使用策略类后如图所示，每个的情况被封装聚合到单个策略类中，相互隔离 所以策略模式的作用主要体现在： 解耦策略的定义、创建和使用 控制代码的复杂度，让每个部分都不至于过于复杂、代码量过多。 让复杂框架满足开闭原则 添加或者修改新策略的时候，最小化、集中化代码改动，减少引入 bug 的风险。 策略的定义 策略的定义包含一个策略接口和一组实现这个接口的策略类。 利用基于接口而非实现编程的方式，对具体策略进行解耦。 如下，策略类ConcreteStrategyA、ConcreteStrategyB在策略接口algorithmInterface的使用上，可以随意替换。 public interface Strategy { //定义策略接口 void algorithmInterface(); } public class ConcreteStrategyA implements Strategy { //实现策略接口的策略类A @Override public void algorithmInterface() { //具体的算法... } } public class ConcreteStrategyB implements Strategy { //实现策略接口的策略类B @Override public void algorithmInterface() { //具体的算法... } } 策略的创建 通常会通过类型（type）来判断创建哪个策略来使用。 这里，有两种创建方式 if-else创建 适用有状态的策略类，每次创建一个新的策略类给业务方使用 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; } } 通过工厂模式里的Map进行创建 适用于无状态的策略类创建，大家共用一个策略类即可 public class StrategyFactory { private static final Map 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); } } 本质上点讲，是借助“查表法”，根据 type 查表替代根据 type 分支判断。 有状态的策略类如何用Map进行创建 可以利用闭包的特性，将创建的逻辑封装进callback中，然后将callback存进Map 策略类的使用 如果使用工厂方法创建策略类，其实就和工厂方法相同。 只不过我们从工厂取出来的不再是一个某一个具体类的子类簇。 而是一个实现了策略接口的类簇。 // 运行时动态确定，根据配置文件的配置决定使用哪种策略 public class Application { public static void main(String[] args) throws Exception { Strategy strategy = null; StrategyFactory factory = new StrategyFactory(); strategy = factory.getStrategy("A"); //获取策略类 strategy.algorithmInterface(); //调用策略接口 //... } } 是不是要抹杀所有的if/else 如果 if-else 分支判断不复杂、代码不多，这并没有任何问题，毕竟 if-else 分支判断几乎是所有编程语言都会提供的语法，存在即有理由。遵循 KISS 原则，怎么简单怎么来，就是最好的设计。非得用策略模式，搞出 n 多类，反倒是一种过度设计