策略模式的介绍
在实际开发过程中，我们常常遇到这样的问题，实现某一个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略来完成该功能，例如，排序算法，可以选择插入排序、冒泡排序等。
针对这种情况，一种常规的方法是将多种算法写在一个类中。例如，需要提供多种排序算法，可以将这些算法写到一个类中，每个方法对应一个具体的排序算法；当然也可以将这些排序算法封装在一个统一的方法中，通过if...else... 或者case 等条件判断语句来选择具体的算法。这两种实现方法我们都可以称为硬编码。然而当很多个算法集中在一个类中时，这个类就会变的臃肿，这个类的维护成本会变高，在维护是也更容易引发错误。如果需要增加一种新的排序算法，需要修改封装算法类的源代码。这就明显违反了我们上面所说的OCP 原则和单一原则。
如果将这些算法或者策略抽象出来，提供一个统一的接口，不同的算法或者策略有不同的实现类，这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换，这种模式的可扩展性、可维护性也就更高，也就是我们本文要说的策略模式。
策略模式的定义
策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
策略模式的使用场景
- 针对同一类型问题的多种处理方式，仅仅是具体行为有差别
- 需要安全地封装多种同一类型的操作
- 出现同一抽象类有多个子类，而又要使用if- else或者switch-case来选择具体子类时
策略模式的UML类图
UML类图如下图所示;
角色介绍
- Context -用来操作策略的上下文环境
- Stragety -策略的抽象
- ConcreteStragetyA、ConcreteStragetyB -具体的策略类实现。
策略模式的简单实现
通常一个问题有多个解决方案时，最简单的方式就是利用if-else或者switch-case方式根据不同的情景选择不同的解决方案，但这种简单的方案问题太多，例如耦合性太高、代码臃肿、难以维护等，但是，如果解决方案中包括大量的处理逻辑需要封装，或者处理方式变动较大的时候则就显得混乱、复杂，当需要增加一种方案时就需要修改类中的代码。
是的，if-else 这种方式确实不会遵循开闭原则，而应对这种情况策略模式能很好的解决这类问题，它将各种方案分离开来，让程序客户端根据具体的需求来动态地选择不同的策略方案。
下面我们以北京坐公共交通工具的费用计算来演示一个简单实例。
import org.junit.Test;
public class PriceCalculator {
//公交车类型
private static final int BUS = 1;
//地铁类型
private static final int SUBWAY = 2;
@Test
public void main() {
PriceCalculator calculator = new PriceCalculator();
System.out.println("坐16km的公交价格为:" + calculator.calculatePrice(16,SUBWAY));
}
/**
* 公交车 十公里内一元，超过十公里之后每加一元可以乘5公里
* @param km
* @return
*/
private int busPrice(int km) {
//超过十公里的总距离
int extraTotal = km - 10;
//超过五公里的倍数
int extraFactor = extraTotal / 5;
//超过的距离对5公里取余
int factor = extraTotal % 5;
//计算价格
int price = extraFactor + 1;
return factor > 0 ? ++price : price;
}
/**
* 6公里(含) 内3元：6-12公里(含) 4元。12-22公里(含) 5元，22-32公里(含) 6元
* @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;
}
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 函数中增加一个判断，代码添加后大致如下：
//出租车类型
private static final int TAXI = 3;
/**
* 出租车价格
* @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 语句缠绕其中，当价格的计算方法变化时，需要直接修改这个类中的代码，那么很有可能有一段代码是其他几个计算方法所共同使用的，这就容易引入错误。另外在增加出行方式时，我们又需要在calculatePrice中添加if-else ，此时很有可能就是复制上一个if-else 然后手动进行修改，手动复制代码也是容易引入错误的做法之一。这类代码是难以应对变化的，它会使代码变得越来越臃肿，难以维护，我们解决这类问题的手法也就是本篇谈到的策略模式。
下面我们对上面示例进行重构。
首先我们需要定义一个抽象的价格计算接口，这里命名为CalculateStrategy ，具体代码如下：
public interface CalulateStrategy {
/**
* 按照距离计算价格
* @param km
* @return
*/
int calculatePprice(int km);
}
对于每一种出行方式我们都有一个独立的计算策略类，这些策略类都实现了CalculateStrategy 接口，例如下面是公交车和地铁的计算策略类。
public class BusStrategy implements CalculateStrategy {
/**
* 公交车 十公里内一元，超过十公里之后每加一元可以乘5公里
*
* @param km
* @return
*/
@Override
public int calculatePprice(int km) {
//超过十公里的总距离
int extraTotal = km - 10;
//超过五公里的倍数
int extraFactor = extraTotal / 5;
//超过的距离对5公里取余
int factor = extraTotal % 5;
//计算价格
int price = extraFactor + 1;
return factor > 0 ? ++price : price;
}
}
public class SubwayStrategy implements CalculateStrategy {
/**
* 6公里(含) 内3元：6-12公里(含) 4元。12-22公里(含) 5元，22-32公里(含) 6元
*
* @return
*/
@Override
public int calculatePprice(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;
}
return 7;
}
}
我们在创建一个扮演Context角色的类，这里将它命名为TranficCalculator ,具体代码如下。
public class TranficCalculator {
@Test
public void main() {
TranficCalculator calculator = new TranficCalculator();
//设置计算策略
calculator.setmStratefy(new SubwayStrategy());
System.out.println("公交车乘16公里的价格："+calculator.calculatePrice(16));
}
CalculateStrategy mStratefy;
public int calculatePrice(int km){
return mStratefy.calculatePrice(km);
}
public void setmStratefy(CalculateStrategy mStratefy) {
this.mStratefy = mStratefy;
}
}
经过上述重构之后，去掉了各种各样的if-else 语句，结构变得也很清晰，其结构如图所示
这种方案在隐藏实现的同时，可扩展线变得很强，例如我们要增加出租车的计算策略时，只需要添加一个出租车的计算策略类，然后将该策略设置给TranficCalculator 最后直接通过TranficCalculator 对象的计算方法即可。例如下面代码：
public class TaxiStrategy implements CalculateStrategy {
@Override
public int calculatePrice(int km) {
return km*2;
}
}
public class TranficCalculator {
@Test
public void main() {
TranficCalculator calculator = new TranficCalculator();
//设置计算策略
calculator.setmStratefy(new TaxiStrategy());
System.out.println("公交车乘16公里的价格："+calculator.calculatePrice(16));
}
CalculateStrategy mStratefy;
public int calculatePrice(int km){
return mStratefy.calculatePrice(km);
}
public void setmStratefy(CalculateStrategy mStratefy) {
this.mStratefy = mStratefy;
}
}
通过上面的实例我们可以清晰地看出二者的区别所在。前者通过if-else 来解决问题，虽然实现 较为简单，类型层级单一，但暴露的问题非常明显，即代码臃肿，逻辑复杂，难以升级和维护，没有结构可言；后者则是通过建立抽象，将不同的策略构建成换一个具体的策略实现，通过不同的策略实现算法的替换。在简化逻辑、结构的同时，增强了系统的可读性、稳定性、可扩展性，这对于较为复杂的业务逻辑显得更为直观，扩展也更为方便。
总结
策略模式主要用于分离算法，在相同的行为抽象下有不同的具体实现策略。这个模式很好地演示了开闭原则，也就是定义抽象，注入不同的实现，从而达到很好的扩展性。
优点
- 结构清晰明了、使用简单直观
- 耦合度相对而言较低，扩展方便
- 操作封装也更为彻底，数据更加安全
缺点
- 随着策略的增加，子类会变的繁多
Demo
参考
《Android源码设计模式》
