今天，我们开始学习另外一种行为型模式，策略模式。在实际的项目开发中，这个模式也比较常用。最常见的应用场景是，利用它来避免冗长的 if-else 或 switch 分支判断。不过， 它的作用还不止如此。它也可以像模板模式那样，提供框架的扩展点等等。
策略模式的原理与实现
策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是 这样定义的：定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码）。
我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式跟两者类似，也能起到解耦的作用，不过，它解耦的是策略的定义、创建、使用这三部 分。接下来，我就详细讲讲一个完整的策略模式应该包含的这三个部分。
1. 策略的定义
策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。因为所有的策略类都实现相同的接口，所以，客户端代码基于接口而非实现编程，可以灵活地替换不同的策 略。示例代码如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public interface Strategy {
void algorithmInterface();
}
public class ConcreteStrategyA implements Strategy {
@Override
public void algorithmInterface() {
}
}
public class ConcreteStrategyB implements Strategy {
@Override
public void algorithmInterface() {
}
}
|
2. 策略的创建
因为策略模式会包含一组策略，在使用它们的时候，一般会通过某种类型（type）来判断创建哪个策略来使用。为了封装创建逻辑，我们需要对客户端代码屏蔽创建细节。我们可以把根 据 type 创建策略的逻辑抽离出来，放到工厂类中。示例代码如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
| 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() 的时候，都创建一个新的策略对象。针对这种情况，我们可以使用上面这种工厂类的实现方式，事先创建好每个策略对象，缓存到工厂类中，用的时候直接返回。
相反，如果策略类是有状态的，根据业务场景的需要，我们希望每次从工厂方法中，获得的都是新创建的策略对象，而不是缓存好可共享的策略对象，那我们就需要按照如下方式来实现策略工厂类。
1
2
3
4
5
6
7
8
9
10
11
12
13
| public class StrategyFactory {
private static final Map<String, Class> strategies = new HashMap<>();
static {
strategies.put("A", ConcreteStrategyA.class);
strategies.put("B", ConcreteStrategyB.class);
}
public static Strategy getStrategy(String type) throws Exception {
if (type == null || type.isEmpty()) {
throw new IllegalArgumentException("type should not be empty.");
}
return (Strategy) strategies.get(type).newInstance();
}
}
|
3. 策略的使用
刚刚讲了策略的定义和创建，现在，我们再来看一下，策略的使用。
我们知道，策略模式包含一组可选策略，客户端代码一般如何确定使用哪个策略呢？最常见 的是运行时动态确定使用哪种策略，这也是策略模式最典型的应用场景。
这里的“运行时动态”指的是，我们事先并不知道会使用哪个策略，而是在程序运行期间， 根据配置、用户输入、计算结果等这些不确定因素，动态决定使用哪种策略。接下来，我们通过一个例子来解释一下。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
public class UserCache {
private Map<String, User> cacheData = new HashMap<>();
private Strategy strategy;
public UserCache(Strategy strategy) {
this.strategy = strategy;
}
public void cacheUserInfo() {
strategy.algorithmInterface();
}
}
public class Application {
public static void main(String[] args) throws Exception {
Properties props = new Properties();
props.load(new FileInputStream("./config.properties"));
String type = props.getProperty("eviction_type");
Strategy strategy = StrategyFactory.getStrategy(type);
UserCache userCache = new UserCache(strategy);
userCache.cacheInfo();
}
}
public class Application {
public static void main(String[] args) {
Strategy strategy = new ConcreteStrategyA();
UserCache userCache = new UserCache(strategy);
}
}
|
从上面的代码中，我们也可以看出，“非运行时动态确定”，也就是第二个 Application 中的使用方式，并不能发挥策略模式的优势。在这种应用场景下，策略模式实际上退化成了“面向对象的多态特性”或“基于接口而非实现编程原则”。
如何利用策略模式避免分支判断？
实际上，能够移除分支判断逻辑的模式不仅仅有策略模式，状态模式也可以。对于使用哪种模式，具体还要看应用场景来定。 策略模式适用于根据不同类型待动态，决定使用哪种策略这样一种应用场景。
我们先通过一个例子来看下，if-else 或 switch-case 分支判断逻辑是如何产生的。具体的代码如下所示。在这个例子中，我们没有使用策略模式，而是将策略的定义、创建、使用直接耦合在一起。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 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;
}
}
|
如何来移除掉分支判断逻辑呢？那策略模式就派上用场了。我们使用策略模式对上面的代码重构，将不同类型订单的打折策略设计成策略类，并由工厂类来负责创建策略对象。具体的代码如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public interface DiscountStrategy {
double calDiscount(Order order);
}
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);
}
}
|
重构之后的代码就没有了 if-else 分支判断语句了。实际上，这得益于策略工厂类。在工厂类中，我们用 Map 来缓存策略，根据 type 直接从 Map 中获取对应的策略，从而避免 ifelse 分支判断逻辑。等后面讲到使用状态模式来避免分支判断逻辑的时候，你会发现，它们使用的是同样的套路。本质上都是借助“查表法”，根据 type 查表（代码中的 strategies 就是表）替代根据 type 分支判断。