策略模式
一 开发模拟鸭子游戏
已经有一个很成功的鸭子模拟游戏，里面有各种鸭子，一边游泳，一边呱呱叫。该系统采用的标准OO技术，设计了一个鸭子超类，并让各种鸭子继承此超类。
实现如下：超类中定义了鸭子的各种行为，包括呱呱叫，游泳，外观等。由于各种鸭子的外观是不一样的，display方法抽象出来，各个子类各自实现它。
这时候，游戏需要大更新，新增鸭子飞行模式，该怎么办呢？在目前的代码基础上变更如下：在超类中添加飞行行为fly()，这样所有的鸭子子类都继承了飞行方法。
但是游戏上线后，发现所有的鸭子都会飞了，没有翅膀的橡皮鸭也在天上飞，不符合实际。怎么解决？让橡皮鸭重写父类的飞行方法。
总结：这种设计模式，每当有新的鸭子添加进来，都要去确认需不需要重写飞行方法，代码复用率很低且极易出错
二 跳出继承，试试接口
我们现在就变化和不会变化的部分做分割，目前来说，鸭子的呱呱叫和飞行行为是会存在变化的。不会变化的如游泳，外观，继续保持在超类，会变化的行为抽象成
接口，由具体的行为来实现接口。
接口实现如下：
三 整合代码实现
1.我们先创建飞行接口
2.接着实现两种飞行能力，后期有新的飞行能力，可以再添加
3.创建鸭子父类，由于父类决定不了每个鸭子的长相，将外观这个方法抽象，所以父类也为抽象类
4.创建一个毛毛鸭子类
5.测试毛毛鸭的行为，并在运行中动态改变它的飞行能力
运行结果：
四 封装行为的大局观
根据新需求，对模拟鸭子游戏进行重构后，我们所期望的一切都有：鸭子继承父类Duck，飞行行为实现了FlyBehavior接口
这个设计模式就是策略模式，该模式的设计原则是多用组合，少用继承。
如你所见，使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以再运行时动态的改变行为，只要组合的
行为对象符合正确的接口标准即可。
策略模式：定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
UML图如下：
