策略者模式（Strategy Pattern）

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

什么时候使用策略模式呢？它的用武之地是？我们从一个鸭子游戏说起。。。

SimUDuck是某公司做的一套相当成功的模拟鸭子游戏：它能够模拟鸭子的呱呱叫、游泳等行为。

后来由于市场竞争加剧，公司要扩展SimUDuck游戏，以增强竞争力！给鸭子加上飞行行为！

要让鸭子能够飞行？如何来做呢？有以下方法可用：

1、在鸭子基类DuckBase中添加Fly方法，这样派生于DuckBase的所有类的对象就具备了Fly方法，就能够飞行了！很简单，不是吗？轻易得来的东西，靠得住吗？生活中的这条经验，让我们不禁怀疑其来。分析下，所有的派生于DuckBase的类的对象都能Fly！不管啥鸭子，都能飞！橡皮鸭子也能飞！很显然--不合理！不合逻辑！此法不通。

2、那用接口呢？定义FlyInterface接口，让所有能飞的鸭子都实现该接口！貌似是个好方法，但是问题是模拟鸭子游戏已经具备规模了，旗下已经有几十种鸭子了！如果采用此方法，几乎所有的鸭子类都要修改一遍！好麻烦啊！原来好好的代码，都要修改，这将带来多少bug啊！即便是采用该方法，那么以后每隔几周都会增加一种新型鸭子，有的靠火箭助推！有的靠气球飞行！。。。N多的飞行方式，这个FlyInterface就显得不太够用了，飞行方式的具体实现代码要写到具体的鸭子类中，与鸭子类紧紧的耦合到一起了！也就是说飞行的方法不能方便的共享了，比如：

绿头鸭靠翅膀飞；机器鸭靠火箭飞。某一天绿头鸭也想用火箭飞，咋办？是不是得把“火箭飞”代码原封不动的拷贝过来？Mygod，太麻烦了！这要维护多套“火箭飞”代码啊！

那能不能把所有的飞行方法独立出来，独立于鸭子对象？也就是说鸭子类中不在包含具体的飞行代码！飞行代码与鸭子是独立存在的！看下面的方法。。。

3、鸭子类中不能包含具体的飞行代码；飞行代码必须是独立存在的，且能够设定到具体的鸭子类中；鸭子类飞行时，能调用飞行代码；

定义一个FlyBehavior接口，内含一个Fly()方法；FlyWithWings、FlyNoWay、FlyWithXXX类实现FlyBehavior接口。

在鸭子类中包含FlyBehavior类型的成员变量，这样具体的飞行方法类就能够赋予到鸭子对象上了，自然鸭子对象就能够用各种设定的方式飞行了！

策略模式遵循几个原则：多用组合，少用继承；针对接口编程-针对超类型编程。目的就是将一切可能变化的东西独立出来，封装好，让软件已于维护，方便扩展。

此文为总结Head First 设计模式一书中的策略模式