5. 效果
    Strategy模式具有以下优点：
    1) 相关算法系列：Strategy类层次为Context定义了一系列的可重用的算法或者行为。继承有助于析取算法中的公共功能，例如参数合法性验证，可以放在Strategy类层次；
    2) 消除一些条件语句：Strategy模式提供了用体检语句选择所需的行为以为的另外一种选择。当不同的行为堆砌在一个类中，很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句；
    3) 选择合适的实现：Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间/空间权衡取舍要求不同策略中进行选择。
    然而世界上没有完美的事情，Strategy模式在带来方便的同时，也存在如下的一些缺点： 
    1) 客户必须了解不同的Strategy：这是本模式潜在的一个缺点，其实客户要选择一个合适的Strategy就必须知道这些Strategy有何不同。这不可避免地向客户暴露具体的实现问题。
    2) Strategy和Context之间的通信开销：无论各个ConcreteStrategy实现算法是简单还是复杂，它们都共享Strategy定义的接口。因此，很有可能具体的ConcreteStrategy（有些ConcreteStrategy可能非常简单，不需要太多的参数）不会用到通过这个接口传递的某些信息，这样就会造成信息的浪费；
    3) 增加了对象的数目：Strategy增加了一个应用中的对象的数目（譬如有多个上下文的时候，每个上下文中都存在Strategy对象）。有时候你可以将Strategy实现为可供各个Context共享的无状态的对象来减少这以开销。

    6. 总结
    本人曾经参与了总装某个型号任务的开发，整个项目中有许多地方可以用到Strategy模式。然而非常可惜的是，由于时间紧急，许多开发人员仓促上阵，只注重具体细节的实现，并没有把这些细节中的共同的东西抽象出来，造成了项目臃肿，代码量非常大，而且耦合非常紧密，导致Bug丛生。好在后来我们意识这一点，对代码进行了Review，调整了代码结构，其中就包括应用Strategy等许多设计模式，最终还是取得了成功。