策略模式
策略模式
1. 概述
先看下面的图片，我们去旅游选择出行方式有很多种，可以骑自行车、可以坐汽车、可以坐火车、可以坐飞机。
作为一个程序员，开发需要选择一款开发工具，可以进行代码开发的工具有很多，可以选择 IDEA 进行开发，也可以使用 Eclipse 进行开发，也可以使用其他的一些开发工具。
定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。
提示
策略模式解决的核心问题只有一个：同一件事有多种做法，而且做法之间需要灵活替换。把"做法"抽成独立的类，让"调用做法的人"只依赖统一接口，就能做到随时换算法而不动业务代码。
2. 结构
策略模式的主要角色如下：
| 角色 | 说明 |
|---|---|
| 抽象策略（Strategy）类 | 抽象角色，通常由一个接口或抽象类实现，给出所有具体策略类所需的接口 |
| 具体策略（Concrete Strategy）类 | 实现抽象策略定义的接口，提供具体的算法实现或行为 |
| 环境（Context）类 | 持有一个策略类的引用，最终给客户端调用 |
3. 案例实现
【例】促销活动。
一家百货公司在定年度的促销活动。针对不同的节日（春节、中秋节、圣诞节）推出不同的促销活动，由促销员将促销活动展示给客户。类图如下：
代码如下。
定义百货公司所有促销活动的共同接口（抽象策略角色）：
public interface Strategy {
void show();
}定义具体策略角色：每个节日具体的促销活动。
// 为春节准备的促销活动A
public class StrategyA implements Strategy {
public void show() {
System.out.println("买一送一");
}
}
// 为中秋准备的促销活动B
public class StrategyB implements Strategy {
public void show() {
System.out.println("满200元减50元");
}
}
// 为圣诞准备的促销活动C
public class StrategyC implements Strategy {
public void show() {
System.out.println("满1000元加一元换购任意200元以下商品");
}
}定义环境角色：用于连接上下文，即把促销活动推销给客户，这里可以理解为销售员。
public class SalesMan {
// 持有抽象策略角色的引用
private Strategy strategy;
public SalesMan(Strategy strategy) {
this.strategy = strategy;
}
// 向客户展示促销活动
public void salesManShow() {
strategy.show();
}
}注
实际使用中，环境角色往往还会提供 setStrategy() 方法，让策略可以在运行期被动态替换；客户端也可以把不同策略传入构造方法，实现"同一个销售员，不同节日喊不同的促销话术"。
4. 优缺点
4.1 优点
- 策略类之间可以自由切换：由于策略类都实现同一个接口，所以它们之间可以自由切换；
- 易于扩展：增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合"开闭原则"；
- 避免使用多重条件选择语句：把
if-else分支替换成独立的策略类，充分体现面向对象设计思想。
4.2 缺点
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类；
- 策略模式会造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。
5. 使用场景
- 一个系统需要动态地在几种算法中选择一种时，可将每个算法封装到策略类中；
- 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，可将每个条件分支移入它们各自的策略类中以代替这些条件语句；
- 系统中各算法彼此完全独立，且要求对客户隐藏具体算法的实现细节时；
- 系统要求使用算法的客户不应该知道其操作的数据时，可使用策略模式来隐藏与算法相关的数据结构；
- 多个类只区别在表现行为不同，可以使用策略模式，在运行时动态选择具体要执行的行为。
6. JDK 源码解析
Comparator 中的策略模式。在 Arrays 类中有一个 sort() 方法，如下：
public class Arrays {
public static <T> void sort(T[] a, Comparator<? super T> c) {
if (c == null) {
sort(a);
} else {
if (LegacyMergeSort.userRequested)
legacyMergeSort(a, c);
else
TimSort.sort(a, 0, a.length, c, null, 0, 0);
}
}
}Arrays 就是一个环境角色类，这个 sort 方法可以传一个新策略让 Arrays 根据这个策略来进行排序。比如下面的测试类。
public class Demo {
public static void main(String[] args) {
Integer[] data = {12, 2, 3, 2, 4, 5, 1};
// 实现降序排序
Arrays.sort(data, new Comparator<Integer>() {
public int compare(Integer o1, Integer o2) {
return o2 - o1;
}
});
System.out.println(Arrays.toString(data)); // [12, 5, 4, 3, 2, 2, 1]
}
}这里我们在调用 Arrays 的 sort 方法时，第二个参数传递的是 Comparator 接口的子实现类对象。所以 Comparator 充当的是抽象策略角色，而具体的子实现类充当的是具体策略角色。环境角色类（Arrays）应该持有抽象策略的引用来调用。那么，Arrays 类的 sort 方法到底有没有使用 Comparator 子实现类中的 compare() 方法呢？让我们继续查看 TimSort 类的 sort() 方法，代码如下：
class TimSort<T> {
static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,
T[] work, int workBase, int workLen) {
assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;
int nRemaining = hi - lo;
if (nRemaining < 2)
return; // Arrays of size 0 and 1 are always sorted
// If array is small, do a "mini-TimSort" with no merges
if (nRemaining < MIN_MERGE) {
int initRunLen = countRunAndMakeAscending(a, lo, hi, c);
binarySort(a, lo, hi, lo + initRunLen, c);
return;
}
// ...
}
private static <T> int countRunAndMakeAscending(T[] a, int lo, int hi, Comparator<? super T> c) {
assert lo < hi;
int runHi = lo + 1;
if (runHi == hi)
return 1;
// Find end of run, and reverse range if descending
if (c.compare(a[runHi++], a[lo]) < 0) { // Descending
while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) < 0)
runHi++;
reverseRange(a, lo, runHi);
} else { // Ascending
while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) >= 0)
runHi++;
}
return runHi - lo;
}
}上面的代码中最终会跑到 countRunAndMakeAscending() 这个方法中。我们可以看见，排序过程中只用了 compare 方法，所以在调用 Arrays.sort 方法时只需要传入重写了 compare 方法的类对象即可，这也是 Comparator 接口中要求子类必须实现的一个方法。
提示
如果使用 JDK 8 及以上版本，上面降序排序的匿名内部类可以直接替换为 Lambda 写法：Arrays.sort(data, (o1, o2) -> o2 - o1);，策略的实现更简洁，但模式本身的结构没有变化。