016-设计模式一：策略模式(Strategy)

上一篇：015-CFBridgingRelease简析

一、说白了

所谓策略模式(Strategy)，说白了就是：定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。也称为政策模式(Policy)。

二、举例

• 出去旅游：我们有多种策略可选，走路、骑单车、自驾、坐火车、坐飞机等。

• 银行存款：我们有多种策略可选，定期、活期等。

三、优点

1、避免使用多重条件判断。

我们当然可以使用if 和else if来实现所需算法，但我们为什么要使用策略模式而不是直接使用if判断语句呢？我个人理解有以下几点。

• 算法相近，if和else if多来几个，而且又是涉及到算法，一般而言代码都比较长。一旦修改、增加或者删除时，一不小心出错，就出大事了。而用策略模式的话，一种算法一个类。修改就只修改需要被修改的那个类，添加直接新建一个类，完全不担心影响到其他类。删除就直接删除掉需要被删除的类。相对而言，使用策略模式更加稳当！

• 多人合作时，各自管各自的类。如出去旅游的例子，小A写自驾的代码、小B写火车的代码、小C写飞机的代码。由于时间紧急，三个人同时开发，下班前都提交各自代码到代码库。使用策略模式时，每个人都有自己的类，别人的类都不管不动，提交时完全无冲突。若是用if，一不小心就冲突了，甚至写之前商量好了，但写好一提交就冲突。然后又是一波加班解决冲突，闹心。

• 策略清晰，由于每种策略一个类。板着手指数有多少策略就行，相对而言if就隐晦一点。其他等等。

2、算法可以自由切换。

想换算法比较方便、简单。

3、扩展性良好。

来一个新人，新加一种算法，直接新建一个类就写，减少甚至避免了阅读前人代码。最怕的是上来就先看几天前人写的代码再开工，而且看得不是很明白心里虚虚的。

4、提供相同行为的不同实现。

客户可以根据不同时间 /空间权衡取舍要求从不同策略中进行选择。

四、缺点

1、策略类较多。

使用策略模式，一般会造成类比较多。

2、所有策略类都需要对外暴露。

一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。

3、Strategy和Context之间的通信开销。

使用到Context的话，可能会有额外开销。

无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的 ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。

五、结构

策略模式结构.jpg

六、使用场景

1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。

2、一个系统需要动态地在几种算法中选择一种。

3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

七、注意点

• 如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

• 如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…或者case等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法，该类代码将较复杂，维护较为困难。如果我们将这些策略包含在客户端，这种做法更不可取，将导致客户端程序庞大而且难以维护，如果存在大量可供选择的算法时问题将变得更加严重。

八、模式的组成

• 环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据。

• 抽象策略类(Strategy):定义所有支持的算法的公共接口。 Context使用这个接口来调用某ConcreteStrategy定义的算法。

• 具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。

九、总结分析

• 策略模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法封装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。

• 在策略模式中，应当由客户端自己决定在什么情况下使用什么具体策略角色。

• 策略模式仅仅封装算法，提供新算法插入到已有系统中，以及老算法从系统中“退休”的方便，策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定。这在一定程度上提高了系统的灵活性，但是客户端需要理解所有具体策略类之间的区别，以便选择合适的算法，这也是策略模式的缺点之一，在一定程度上增加了客户端的使用难度。

十、个人总结

正常写代码一般而言用不到这种模式，但还是有必要知道这种模式的。在对代码进行优化的时候，可以使用策略模式。用到的场景相对是比较少的。

下一篇：017-设计模式二：适配器模式(Adapter)