算是读书笔记吧
极客时间--设计模式之美
什么是策略模式
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 多类，反倒是一种过度设计