设计模式学习（二）：Strategy

说明：由于本人是一个初学者，所以博客中用到的一些见解、图片、代码或者说明可能引用网络上面的资源，如果涉及到了侵权的问题请大家联系我进行删除。

接下来我们来进行第二个设计模式的学习。Strategy(策略）模式同样属于组件协作模式，和template method模式有着异曲同工之妙。

---

首先我们来看一个**例子**：

我们都知道，对于中国出口的同一件产品，每一个国家对它所征收的关税是不一样的，也就是说每一个国家的关税计算方法是不一样的。为了在程序中表达这样的差异，我们可以采用两种设计方法：

• 第一种是采用结构化设计中的分支结构（判断语句）进行判断，对每一种关税的计算方法进行选择，直到选到了适合自己的那一种计算方法。
• 第二种是采用面向对象设计中的动态绑定进行实现，就是将父类中的关税计算的方法设置成虚函数，每一种关税实现一个子类，并继承自父类，实现父类中的虚函数，当需要进行关税调用的时候只要调用相对应的子类中的那一个函数就可以了。

---

接下来我们来看一下本模式使用的**动机**：

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一种性能负担。

结合例子理解上面的这一段话：

1. 当使用第一种设计方法进行设计的时候，我们的程序可能会显得非常冗余，不管是使用if…else…还是使用switch…case…结构，都会使我们的程序中出现大量相同的结构，这样也就大大降低了程序的可读性，增加了程序的复杂性，同时也降低了程序的美观程度。
2. 当我们需要对关税的种类进行修改的（增加或者删除）时候，第一种方法需要对已经编译好的源程序进行修改，这是非常不方便的，而第二种方法只需要对我们想要修改的关税计算方法进行修改就可以了。
3. 还有很重要的一点就是性能问题，当使用分支结构时，我们可能需要对每一种关税计算方法进行判断才能得出我们想要的答案，而第二种方法只需要进行一次多态调用就可以了，这会造成效率上的巨大差异；同时，第一种方法会很大程度上的增加程序在编译运行时的资源占用量。

---

**模式的定义：** 定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展，子类化）。

---

**总结：**

当使用一系列并行调用的算法时，如果算法可能会发生变化，那么我们就需要使用Strategy模式来替代分支结构。（其实我们使用的大部分if…else…结构都可以替换成Strategy模式）。