Java设计模式之——策略模式

策略模式的简单介绍

在软件开发中常常遇到这样的情况：实现某一个功能可以有多种算法或者策略，我们根据事件情况选择不同的算法或者策略来完成该功能。例如，排序算法，可以使用插入排序、归并排序、冒泡排序等。

这对这种情况，一个常规的方法是将多种算法写在一个类中。例如，需要提供多种排序算法。可以将这些算法写到一个类中，每一个方法对应一个具体的排序算法；当然，也可以将这些排序算法封装到一个统一的方法中，通过 if….else… 或者 case 等条件判断语句来选择具体的算法。这两种实现方式都可以称为硬编码。然而，当很多个算法集中在一个类中时，这个类就会变得臃肿，这个类的维护成本也会变高，在维护时也更容易引发错误。如果我们需要增加一种新的排序算法，需要修改封装算法类的源代码。这就明显违反了我们前面博客中所说的 SOLID 原则中的开闭原则和单一职责原则。

如果将这些算法或者策略抽象出来，提供一个统一的接口，不同的算法或者策略有不同的实现类，这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换，这种模式的可扩展性、可维护性也就更高，也就是我们接下来要说的策略模式。

策略模式的定义

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以互相替换。策略模式让算法独立于使用它的客户而独立变化。

策略模式的使用场景

针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
需要安全地封装多种同一类型的操作时。
出现同一抽象类有多个子类，而又需要使用 if-else 或者 switch-case 来选择具体子类时。

策略模式的 UML 类图

角色介绍：

Context —— 用来操作策略的上下文环境；
Strategy —— 策略的抽象接口；
ConcreteStrategyA、ConcreteStrategyB —— 具体的策略实现。

策略模式实战

通常如果一个问题有多个解决方案时，最简单的方式就是利用 if-else 或者 switch-case 方式根据不同的情景选择不同的解决方案，但这种简单的方案问题太多，例如耦合性太高、代码臃肿、难以维护等。如果解决方案中包括大量的处理逻辑需要封装，或者处理方式变动较大的时候则就会显得混乱、复杂，当需要增加一种方案时就需要修改类中的代码。怎么对于修改不关闭？不是说好的要遵循开闭原则么？

是的，if-else 这种方法确实不会遵循开闭原则，而应对这种情况策略模式就能很好地解决这类问题，它将各种方案分离开来，让程序客户端根据具体的需求来动态地选择不同的策略方案。

下面我们以在北京坐公共交通工具的费用计算来演示一个简单示例。北京的公交大家都知道，是分段计价的，也就是说乘坐的距离越远，价格越高。显然，公交车和地铁的价格计算方式是不一样的，但是我们的示例中是需要计算乘不同出行工具的成本，下面是我们的第一版本的代码：

public class PriceCalculator{//公交车类型private static final int BUS = 1;//地铁类型private static final int SUBWAY = 2;public void main() {Log.d("Test", "坐16公里的公交票价为：" + calculatePrice(16, BUS));Log.d("Test", "坐16公里的地铁票价为：" + calculatePrice(16, SUBWAY));}private int calculatePrice(int km, int type) {if (type == BUS) {return busPrice(km);} else if (type == SUBWAY) {return subwayPrice(km);}return 0;}/*** 北京地铁，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;}/*** 北京公交车，十公里之内一元钱，超过十公里之后每加一元钱可以乘坐5公里** @param km 公里* @return*/private int busPrice(int km) {//超出十公里的部分int extraTotal = km - 10;//超过的距离是 5 公里的倍数，并不足五公里按 5公里计算int extraPrice = (int) Math.ceil(extraTotal / 5.0);return extraPrice + 1;}
}

PriceCalculator 类很明显的问题就是并不是单一职责，首先它承担了计算公交车和地铁乘坐价格的职责；另一个问题就是通过 if-else 的形式来判断使用哪种计算形式。当我们增加一种出行方式时，例如出粗车，那么我们就需要在 PriceCalculator 类中增加一个方法来计算出粗车的出行价格，并且在 calculatePrice(int km, int type) 函数中增加一个判断，代码大致添加后如下：

    private int calculatePrice(int km, int type) {if (type == BUS) {return busPrice(km);} else if (type == SUBWAY) {return subwayPrice(km);} else if (type == TEXT) {return taxiPrice(km);}return 0;}/*** 简单计算为每公里 2元钱** @param km* @return*/private int taxiPrice(int km) {return 2 * km;}

此时的代码已经比较混乱，各种 if-else 语句缠绕其中。当价格的计算方法变化时，需要直接修改这个类中的代码，那么很有可能有一段代码是其他几个计算方法所共同使用的，这就容易引入错误。另外，在增加出行方式时，我们又需要在 calculatePrice 中添加 if-else，此时很有可能就是复制上一个 if-else，然后手动进行修改，手动复制代码也是最容易引入错误的做法之一。这类代码必然是难以应对变化的，它会使得代码变得越来越臃肿，难以维护，我们解决这类问题的手法也就是下面要使用的策略模式。当然，我们也可以把每种计算方法独立成一个函数，然后外部调用对应的方法即可，但这也是另一种耦合的形式，对于可变性较大的算法族来说还是不适合使用这种方式。

下面我们对上述示例用策略模式进行重构。
首先我们需要定义一个抽象的价格计算接口，这里命名为 CalculateStrategy，具体代码如下：

//计算接口
public interface CalculateStrategy {/*** 按距离来计算价格* @param km    公里* @return  返回价格*/int calculatePrice(int km);
}

对于每一种出行方式我们都有一个独立的计算策略类，这些策略类都实现了 CalculateStrategy 接口，例如下面是公交车和地铁的计算策略类：

//公交车价格计算策略
public class BusStrategy implements CalculateStrategy {/*** 北京公交车，十公里之内一元钱，超过十公里之后每加一元钱可以乘坐5公里** @param km 公里* @return*/@Overridepublic int calculatePrice(int km) {//超出十公里的部分int extraTotal = km - 10;//超过的距离是 5 公里的倍数，并不足五公里按 5公里计算int extraPrice = (int) Math.ceil(extraTotal / 5.0);return extraPrice + 1;}
}//地铁价格计算策略
public class SubwayStrategy implements CalculateStrategy {/*** 北京地铁，6公里（含）内3元；6·12公里（含）4元；12·22公里（含）5元；22·32公里（含）6元** @param km* @return*/@Overridepublic 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 角色的类，这里将它命名为 TranficCalculator，具体代码如下所示：

//出行价格计算器
public class TranficCalculator {CalculateStrategy mStrategy;public void main() {//设置计算策略setStrategy(new BusStrategy());//计算价格Log.d("Test", "坐16公里的公交票价为：" + calculatePrice(16));//设置计算策略setStrategy(new SubwayStrategy());//计算价格Log.d("Test", "坐16公里的地铁票价为：" + calculatePrice(16));}//获取价格public int calculatePrice(int km) {return mStrategy.calculatePrice(km);}//设置策略public void setStrategy(CalculateStrategy busStrategy) {this.mStrategy = busStrategy;}
}

这种方案在隐藏实现的同时，可扩展性变得很强，例如，当我们需要增加出粗车的计算策略时，只需要添加一个出粗车计算策略类，然后将该策略设置给 TranficCalculator，最后直接通过 TranficCalculator 对象的计算方法即可。示例代码如下：

//出粗车计算策略
public class TaxiStrategy implements CalculateStrategy {/*** 简单计算为每公里 2元钱** @param km* @return*/@Overridepublic int calculatePrice(int km) {return 2 * km;}
}

将策略注入到 TranficCalculator 中：

//出行价格计算器
public class TranficCalculator {CalculateStrategy mStrategy;public void main() {//设置计算策略setStrategy(new TaxiStrategy());//计算价格Log.d("Test", "坐16公里的出粗车票价为：" + calculatePrice(16));}//获取价格public int calculatePrice(int km) {return mStrategy.calculatePrice(km);}//设置策略public void setStrategy(CalculateStrategy busStrategy) {this.mStrategy = busStrategy;}
}

通过上述示例我们可以清晰地看出二者的区别所在。前者通过 if-else 来解决问题，虽然实现较为简单，类型层次单一，但暴露的问题非常明显，即代码臃肿，逻辑复杂，难以升级和维护，没有结构而言；后者则是通过建立抽象，将不同的策略构建成一个具体的策略实现，通过不同的策略实现算法替换。在简化逻辑、结构的同时，增强了系统的可读性、稳定性、可扩展性，这对于较为复杂的业务逻辑显得更为直观，扩展也更为方便。

总结

策略模式主要用来分离算法，在相同的行为抽象下有不同的具体实现策略。这个模式很好地演示了开闭原则，也就是定义抽象，注入不同的实现，从而达到很好的可扩展性。

优点：

结构清晰明了，使用简单直观；
耦合度相对而言较低，扩展方便；
操作封装也更为彻底，数据更为安全。

缺点：

随着策略的增加，子类也会变得繁多。