策略模式应用

定义：定义了算法族，分别封装起来，让他们之间可以相互替换。此模式让算法的变化独立于使用算法的客户。
体现了：封装变化；少用继承，多用组合；针对接口编程，不针对实现编程

对于Strategy模式来说，主要有这些应用场景：

1、  多个类只区别在表现行为不同，可以使用Strategy模式，在运行时（客户）动态选择具体要执行的行为。(例如FlyBehavior和QuackBehavior)

2、  需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。(例如FlyBehavior和QuackBehavior的具体实现可任意变化或扩充)

3、  对客户(Duck)隐藏具体策略(算法)的实现细节，彼此完全独立。

 

对于Strategy模式来说，主要有如下优点：
0、 相关算法系列： Strategy类层次为Context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。

1、  提供了一种替代继承的方法，而且既保持了继承的优点(代码重用)还比继承更灵活(算法独立，可以任意扩展)。

2、  避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。

3、  遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

对于Strategy模式来说，主要有如下缺点：
1、因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。
2、客户端必须知道所有的策略类，并自行决定使用哪一个策略类:  本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。
3、Strategy和Context之间的通信开销 ：无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的 ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。