设计模式之策略模式

一、什么是策略模式？

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换。此模式让算法的变化独立于使用算法的客户。核心思想是将变化的部分抽离为独立维度。

二、从鸭子示例窥探策略模式的优势

• 需求版本一：

           鸭子种类：绿头鸭、红头鸭、橡皮鸭

 行为：quack()---呱呱叫，swim()---游泳，display()---展示外观。

 附：橡皮鸭不会呱呱叫，而是吱吱叫。

 可能我们会这么设计：

• 需求版本二：

          鸭子种类：绿头鸭，红头鸭，橡皮鸭，木头鸭

行为：quack()，swim()，display()，fly()---飞行

附：橡皮鸭会吱吱叫不会飞，木头鸭不会叫不会飞。其他的鸭子会呱呱叫会飞。

这时候我们有以下几种思路

1.将fly()方法放入抽象父类Duck中，这样所有的鸭子子类都需要实现fly()方法，即使它不会飞，虽然我们可以为不会飞的鸭子提供空的fly()方法实现。但是这种封装逻辑还是会很奇怪。

1.1将fly()实现放在Duck中的时候，对于可维护、可扩展性是不好的。（比如说我后面又需要区分会飞鸭子，进行不同的飞行 处理，那么只能够在子类中覆盖fly()方法，这显然是不符合OCP原则的，长期如此系统会变得难以维护。其中RubberDuck提供fly()的空实现，DecoyDuck提供quack()和fly()的空实现）

1.2将fly()的抽象放到Duck中，实现放到子类中的时候，就会有大量重复的代码（红框），因为很多鸭子的飞行行为是完全一致的。（其中RubberDuck提供fly()的空实现，DecoyDuck提供quack()和fly()的空实现）

2.将鸭子的不同行为抽象为接口

这样做也是有问题的。

其一是不易于扩展，以后我要是说swim()行为也有新品种的鸭子没法游泳。咋办，你还得动现在的类，不符合OCP，随着鸭子种类的增加，这种问题随时会出现。

其二是大量重复的代码，，接口相比于抽象类就是没有办法提供公有的实现。导致MallardDuck和RedheadDuck中有重复的代码，意味着你需要维护两份。

3.可能有些朋友第一反应是既然接口不行，我用抽象类啊，将Flyable和Quackable写成抽象类，将公有的实现放在里面不就结了？

然而Java不支持多继承。。就算是支持，如果以后要区分对待也是不好处理的。

4.将变化的和不变的分离，将不变的抽离出来，并用组合的方式建立与不变部分的关联，就是我们要讲的策略模式

这种做法看起来似乎很复杂。但事实上是极好的。后面只要有什么行为需要独立于鸭子使用，都可以扩展出一个新的族，现有的族也很好扩展。并且通过组合与Duck关联，耦合性低。

三、策略模式通用UML图