三、设计模式 - 策略者模式(Strategy Method)

1、动机

     在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一种负担。如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题。

2、下面以各个国家税率算法为例来讲解：

枚举TaxBase表示计算税率算法各个国家，SaleOrder表示业务，CalculateTax表示税率计算的方法（下面简称“税法”）。

一段代码放在静态环境中是看不出问题的，现在我们把问题放在时间轴上去看：假设我们现在业务扩展，需要支持法国的税率，我们可以这样改动：

回想一下我们的设计原则，这里明显违背一个原则：开闭原则。（对扩展开放，对内部更改封闭）

设计原则要求我们不要尝试在一个已建好楼房框架情况下再增加一个“地下室”，也就是尽量不要冲击已有框架。那我们换个设计思路：

如上，计算税法，我们单独提取一个基类出来（TaxStrategy），里面只包含一个接口：税率算法（Calculate），然后让各个国家的税法去继承它，并重写自己的税法。

我们对比看一下两种方式：

显然使用策略者模式几乎不用改变已有框架，而是以扩展的方式，而且因为是运行时绑定，性能负担也会小一些（整个程序比较小，这个例子几乎可以忽略）

3、总结

       （1）strategy及其子类为组件提供了一系列可重用的算法，从而使得类型在运行时方便地根据需求在算法间进行切换

       （2）strategy提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦，含有许多条件判断语句的代码通常都可以使用strategy

        （3）如果strategy对象没有实例变量，那么各个上下文可以共享同一个strategy对象，从而节省对象开销