第一式 策略模式

策略模式

一 开发模拟鸭子游戏

　　已经有一个很成功的鸭子模拟游戏，里面有各种鸭子，一边游泳，一边呱呱叫。该系统采用的标准oo技术，设计了一个鸭子超类，并让各种鸭子继承此超类。

　　实现如下：超类中定义了鸭子的各种行为，包括呱呱叫，游泳，外观等。由于各种鸭子的外观是不一样的，display方法抽象出来，各个子类各自实现它。

　　

　　这时候，游戏需要大更新，新增鸭子飞行模式，该怎么办呢？在目前的代码基础上变更如下：在超类中添加飞行行为fly()，这样所有的鸭子子类都继承了飞行方法。

　　但是游戏上线后，发现所有的鸭子都会飞了，没有翅膀的橡皮鸭也在天上飞，不符合实际。怎么解决？让橡皮鸭重写父类的飞行方法。

　　总结：这种设计模式，每当有新的鸭子添加进来，都要去确认需不需要重写飞行方法，代码复用率很低且极易出错

二 跳出继承，试试接口

　　我们现在就变化和不会变化的部分做分割，目前来说，鸭子的呱呱叫和飞行行为是会存在变化的。不会变化的如游泳，外观，继续保持在超类，会变化的行为抽象成

　　接口，由具体的行为来实现接口。

　　接口实现如下：

　　

三 整合代码实现

 　　1.我们先创建飞行接口

　　

　　2.接着实现两种飞行能力，后期有新的飞行能力，可以再添加

　　

　　

　　3.创建鸭子父类，由于父类决定不了每个鸭子的长相，将外观这个方法抽象，所以父类也为抽象类

　　

　　4.创建一个毛毛鸭子类

　　

　　5.测试毛毛鸭的行为，并在运行中动态改变它的飞行能力

　　

　　运行结果：

　　

四 封装行为的大局观

　　根据新需求，对模拟鸭子游戏进行重构后，我们所期望的一切都有：鸭子继承父类duck，飞行行为实现了flybehavior接口

　　这个设计模式就是策略模式，该模式的设计原则是多用组合，少用继承。

　　如你所见，使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以再运行时动态的改变行为，只要组合的

　　行为对象符合正确的接口标准即可。

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

　　uml图如下：