● 策略模式介绍
在软件开发中常常遇到这样的情况：实现某一个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略来完成该功能。例如，排序算法，可以使用插入排序、归并排序、冒泡排序。
针对这种情况，一种常规的方法时将多种算法写在一个类中。例如，需要提供多种排序算法，可以将这些算法写在一个类中，每一个方法对应具体的排序算法；当然，也可以将这些排序算法封装在一个统一的方法中，通过if...else...或者case等条件判断语句来选择具体的算法。这两种实现方式我们都可以称为硬编码。然而，当很多个算法集中在一个类中时，这个类就会变的很臃肿，这个类的维护成本会变高，在维护时更容易引发错误。如果我们需要增加一种新的算法，需要修改封装算法类的源代码。这就明显违反了OCP原则和单一职责原则。
如果将这些算法或者策略抽象出来，提供一个统一的接口，不同的算法或者策略有不同的实现类，这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换，这种模式的可扩展性、可维护性也就更高，也就是我们要说的策略模式。
● 策略模式的定义
策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以互相替换。策略模式让算法独立于使用它的客户端而独立变化。
● 策略模式的使用场景
（1）针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
（2）需要安全地封装多种同一类型的操作时。
（3）出现同一抽象类有多个子类，而又需要使用if-else或者swifch-case来选择具体子类时。
● 策略模式的UML类图
UML类图如下图所示：
上图中的角色介绍：
（1）Content——用来操作策略的上下文环境；
（2）Stragety——策略的抽象；
（3）ConcreteAtragetyA、ConcreteStragetyB——具体的策略实现。
● 策略模式的简单实现
通常如果一个问题有多个解决方案时，最简单的方式就是利用if-else或者switch-case方法根据不同的情景选择不同的解决方案，但这种简单的方案问题太多，例如耦合性太高、代码臃肿、难以维护等。但是，如果解决方案中包含大量的处理逻辑需要封装，或者处理方式变动较大的时候则就显得混乱、复杂，当需要增加一种方案时就需要修改类中的代码。怎么对于修改不关闭？不是说好要遵循开闭原则吗？
是的，if-else这种方法确实不会遵循开闭原则，而应对这种情况策略模式就能很好地解决这类问题，它将各种方案分离开来，让程序客户端根据具体的需求来动态地选择不同的策略方法。
下面我们以坐公共交通工具的费用计算来演示一个简单的示例。有一种公交计费方式不再是单一票价制，而是分段计价，这就是说乘坐的距离越远，价格越高。
虽然，公交车和地铁的价格计算方式是不一样的，但是，我们的示例中需要乘不用的出行工具的成本，下面是我们的第一个版本的代码。
public class PriceCalculator {
//公交车类型
private static final int BUS = 1;
//地铁类型
private static final int SUBWAY = 2;
public static void main(String[] args) {
PriceCalculator priceCalculator = new PriceCalculator();
System.out.println("坐16公里的公交车票价为 : " + priceCalculator.calculatePrice(16, BUS));
System.out.println("坐16公里的地铁票价为 : " + priceCalculator.calculatePrice(16, SUBWAY));
}
/**
* 公交车，十公里之内一元钱，超过十公里之后每加一元钱钱可以乘坐五公里
*
* @param km 公里
* @return
*/
private int busPrice(int km) {
//超过十公里的总距离
int extraTotal = km - 10;
//超过的距离是五公里的倍数
int extraFactor = extraTotal / 5;
//超过的距离对五公里取余
int fraction = extraTotal % 5;
//价格计算
int prince = 1 + extraFactor * 1;
return fraction > 0 ? ++prince : prince;
}
/**
* 6 公里(含)内3元；6~12公里（含）4元；12~22公里（含）5元；22~32公里（含）6元
*
* @param km
* @return
*/
private int subwayPrice(int km) {
if (km <= 6) {
return 3;
} else if (km > 6 && km < 12) {
return 4;
} else if (km > 12 && km < 22) {
return 5;
} else if (km > 22 && km < 32) {
return 6;
}
//其他距离我们简化为7元
return 7;
}
int calculatePrice(int km, int type) {
if (type == BUS) {
return busPrice(km);
} else if (type == SUBWAY) {
return subwayPrice(km);
}
return 0;
}
}
PriceCalculator类很明显的问题就是并不是单一职责，首先它承担了计算公交车和地铁乘坐价格的职责；另一个问题就是通过if-else的形式来判断使用哪种计算形式。当我们增加一种出行方式时，如出租车，那么我们就需要在 PriceCalculator中增加一个方法来计算出租车出行的价格，并且在calculatePrice(int km , int type)函数中增加一个判断，代码添加后大致如下。
//公交车类型
private static final int BUS = 1;
//地铁类型
private static final int SUBWAY = 2;
//出租车类型
private static final int TAXI = 3;
/**
* 简单计算为每公里2元钱
*
* @param km
* @return
*/
private int taxiPrice(int km) {
return km * 2;
}
int calculatePrice(int km, int type) {
if (type == BUS) {
return busPrice(km);
} else if (type == SUBWAY) {
return subwayPrice(km);
} else if (type == TAXI) {
return taxiPrice(km);
}
return 0;
}此时的代码已经比较混乱，各种if-else语句缠绕其中。当价格的计算方式变化时，需要直接修改这个类中的代码，那么很可能有一段代码是其他几个计算方法所共同使用的，这就容易引入错误。另外，在增加出行方式时，我们有需要在calclatePrice中添加if-else，此时很有可能就是复制上一个if-else，然后手动修改，手动复制代码也是最容易引入错误的做饭之一。这类代码必然是难以应对变化的，他会使得代码变得越来越臃肿，难以维护，我们解决这类问题的手法也就是策略模式。当然，我们也可以把每种计算方式独立成一个函数，让后外部调用对应的方法即可，但这也是另一种耦合的形式，对于可变性较大的算法族来说还是不合适使用这种方式。
下面我们对上诉示例用策略模式进行重构。
首先我们需要定义一个抽象的价格计算接口，这里命名为CalculateStrategy，具体代码如下。
/**
* 计算接口
*/
public interface CalculateStrategy {
/**
* 按距离来计算价格
*
* @param km 公里
* @return 返回价格
*/
int calculatePrice(int km);
}对于每一种出行方法我们都有一个独立的计算策略类，这些策略类都实现了CalculateStrategy接口，例如下面是公交车和地铁的计算策略类。
/**
* 公交车价格计算类
*/
public class BusStrategy implements CalculateStrategy {
/**
* 公交车，十公里之内一元钱，超过十公里之后每加一元钱可以乘坐五公里
*
* @param km 公里
* @return
*/
@Override
public int calculatePrice(int km) {
//超过十公里的总距离
int extraTotal = km - 10;
//超过的距离是五公里的倍数
int extraFactor = extraTotal / 5;
//超过的距离对五公里取余
int fraction = extraTotal % 5;
//价格计算
int prince = 1 + extraFactor * 1;
return fraction > 0 ? ++prince : prince;
}
}
/**
* 地铁价格计算策略
*/
public class SubwayStrategy implements CalculateStrategy {
/**
* 6 公里(含)内3元；6~12公里（含）4元；12~22公里（含）5元；22~32公里（含）6元
*
* @param km 公里
* @return
*/
@Override
public int calculatePrice(int km) {
if (km <= 6) {
return 3;
} else if (km > 6 && km < 12) {
return 4;
} else if (km > 12 && km < 22) {
return 5;
} else if (km > 22 && km < 32) {
return 6;
}
//其他距离我们简化为7元
return 7;
}
}我们在创建一个扮演Context角色的类，这里将它命名为TrafficCalculator，具体代码如下。
/**
* 公交出行价格计算器
*/
public class TrafficCalculator {
private CalculateStrategy mStrategy;
public static void main(String[] args) {
TrafficCalculator calculator = new TrafficCalculator();
//设置计算策略
calculator.setStrategy(new BusStrategy());
//计算价格
System.out.println("坐16公里的公交车票价为 : " + calculator.calculatePrice(16));
}
public void setStrategy(CalculateStrategy mStrategy) {
this.mStrategy = mStrategy;
}
public int calculatePrice(int km) {
return mStrategy.calculatePrice(km);
}
}经过上诉的重构之后，去掉了各种各样的if-else语句，机构变得也很清晰，其结构图如下：
这种方案在隐藏实现的同时，可扩展性变的很强，例如，当我们需要增加出租车的计算策略时，只需要添加一个出租车计算策略类，然后该策略设置给Traffic
Calcilator，最好直接通过TrafficCalcilator对象的计算方法即可。示例代码如下。
/**
* 公交出行价格计算器
*/
public class TrafficCalculator {
private CalculateStrategy mStrategy;
public static void main(String[] args) {
TrafficCalculator calculator = new TrafficCalculator();
//设置计算策略
calculator.setStrategy(new TaxiStrategy());
//计算价格
System.out.println("出租车乘坐16公里的价格 : " + calculator.calculatePrice(16));
}
public void setStrategy(CalculateStrategy mStrategy) {
this.mStrategy = mStrategy;
}
public int calculatePrice(int km) {
return mStrategy.calculatePrice(km);
}
}
通过上诉示例我们就可以清晰地看出二者的区别所在。前者通过if-else来解决问题，虽然实现较为简单，类型层级单一，但暴露的问题非常明显，即代码臃肿，逻辑复杂，难以升级和维护，没有结构可言；后者则是通过建立抽象，将不同的策略构建成一个具体的策略实现，通过不同的策略实现算法替换。在简化逻辑、结构的同时，增强了系统的可读性、稳定性、可扩展性，这对于较为复杂的业务逻辑显得更为直观，扩展也更为方便。
