策略模式(Strategy Pattern)

例子:

一个游戏中有各种鸭子,红头鸭,绿头鸭等等,很自然得出这样的设计:

这时,需求改变了(永远不变的是改变).游戏需要鸭子能飞起来, 在抽象的Duck类中加入一个方法fly(),是一个很自然的想法.

但是,问题出现了,一些不能飞的鸭子(比如橡皮鸭)也飞了起来.——继承带来的问题：牵一发而动全身

我们可以找到一个暂时的办法：覆盖橡皮鸭的fly()方法，使这个方法什么也不做。然而随着鸭子的数量的增加，你必须检查每一个不会飞，或者不会叫的的鸭子的方法都被覆盖掉了，这个工作量将是巨大的。

此时，另一种设计方式似乎可行：让某些鸭子“可以飞”，“可以叫”——即实现Flyable接口,如图：

这样设计似乎概念上非常清楚，但是带来的问题显而易见：

1) 由于接口中没有方法的实现，不能复用代码，导致许多类中都有大量重复的代码

2) 如果需要修改所有类的quack()方法，需要对大量(比如说48个)子类进行修改

那怎么样设计才好呢？先看一下下面的设计原则：

 1. 找出应用中可能变化指出，把他们独立出来，不要和那些不需要变化的代码混在一起。——把会变化的部分取出来并封装，好让其他部分不受影响。
2. 针对抽象(接口)编程,而不是针对实现编程.

在该场景中，可能变化的是鸭子的行为：即鸭子游泳的行为，鸣叫的行为，不同的鸭子不一样。所以根据原则1我们需要将鸭子的行为独立出来，并且将其抽象，我们只针对鸭子行为的抽象编程。按照这个思路，得出设计：

显然，这样的设计克服了上面几种设计的缺点，它既有继承的优点：重用代码，又克服了它的缺点：不会牵一发动全身，修改一个鸭子的行为，不会影响其他鸭子。它甚至可以在运行时动态的改变鸭子的行为。因为它采用的是组合，而不是继承。

这里得到另一个设计原则

 多用组合，少用继承。

至此，我们可以得出策略模式的定义了：

策略模式定义了算法簇，分别封装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户