“HeadFirst设计模式“：策略模式-创新互联

策略模式

问题的描述：

需求：开发一个鸭子游戏，能游泳，有外观，实现类图如下：

增加的需求：

1. 加入飞行功能

2. 加入呱呱叫的功能。。。等等，暂时的解决方式如下：

上线后出现了些问题：

1. 所有的鸭子都能叫吗？木头鸭子呢？

2. 所有的鸭子都能飞吗？木头鸭子呢？橡皮鸭子呢？

总结下，使用继承的缺点：

1. 代码在多个子类中重复

2. 运行时的行为不容易改变

3. 很难知道鸭子的全部行为

4. 改变会牵一发动全身，造成其他鸭子不想要的改变

5. 。。。

好吧，我们引入接口来进一步修改，类图如下：

问题已经解决了，但是鸭子子类有40多种，我们修改fly方法，难道修改40种样本？以后的维护的坑有点大哦！

总结下，这种方式的缺点：

1. 代码在多个子类中重复

2. 维护成本提高（有40个子鸭子类，要修改fly方法需要改40次？）

3. 。。。

问题不断，我们用设模式来解决这个问题，先看看定义：策略模式：定义算法族，分别封装起来，它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

好，我们修改下，类图如下：

我们用这个模式解决了：

1. 鸭子行为的各种各样性（子类行为和超类没有直接的关系了，添加删除行为不影响继承体系）

2. 代码重用，维护问题（子类太多时修改行为特别麻烦，代码重复，只修改算算法组就搞定）

3. 动态修改行为（Setter和Getter方法来灵活配置行为）

4. 。。。

这章我们学到的设计原则：

设计原则1： 封装变化（找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起）。

设计原则2： 针对接口编程，而不是针对实现类

设计原则3： 多用组合，少用继承