策略模式
1）首先我们设计一个鸭子游戏，根据OO技术，我们首先想到的是建一个超类，然后用超类去处理所有鸭子共有的能力（比如呱呱叫、游泳），然后由其他类别的鸭子去继承这个超类，在派生类中去实现每个鸭子独有的特征。
2）那我们考虑一下，改用接口怎么样？
3）解决问题的设计原则
4）实施
5）实现鸭子的行为
6）整合鸭子的行为
7）封装行为的大局观
8）小结

新需求：现在我们要使一些鸭子具有会飞的能力，怎么办？

想到：我们可以在超类中增加fly()方法，然后所有鸭子都去继承这个fly()。

问题：然后我们发现，一些不应该具备飞这个能力的鸭子也会飞了？（比如橡皮鸭子）怎么办？

此时我们会发现，我们针对代码所做的局部修改，影响层面远远不只是局部。

解决：我们想到可以在派生类中去覆盖掉超类的fly()方法。让橡皮鸭子在fly()方法中啥也不干。

发现：我们发现用继承的方式去实现上述的鸭子游戏，会导致诸多缺点：

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

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

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

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

2）那我们考虑一下，改用接口怎么样？

我们将飞和叫的能力从鸭子超类中拿出来，分别放入到Flyable和Quackable接口中。（因为并不是所有的鸭子都会飞，或者都会叫）

问题：这样是解决了我们不厌其烦地去覆盖超类方法的机械工作，但是我们仿佛又跳入了另外一个大坑：代码无法复用。

比如，现在我们要稍稍修改一下会飞鸭子的飞行行为，怎么办？只能一个一个地去修改每一个具体地鸭子，这简直是个更大的恶梦。

对于这个问题我们会用老办法找出一个解决之道：

“采用良好的OO软件设计原则”。

3）解决问题的设计原则

把会变化的部分取出并“封装”起来，好让其他部分不会受到影响。

这会让我们的代码变化引起的不经意后果变少，系统变得更有弹性。

4）实施

我们知道Duck类中的fly()和quack()会随着鸭子的不同而改变，为了要把这两个行为从Duck类中分开，我们将它们从Duck类中取出，建立一组新类来代表每个行为。

那么怎么设计实现飞行和呱呱叫的行为的类呢？

根据第二个设计原则：

我们用接口去代表每个行为。所以这次鸭子类不会负责实现Flying和Quacking接口，反而是由我们制造一组其他类专门实现FlyBehavior与QuackBehavior，这就称为“行为”类。

这种做法迥异于以往，以前的做法是：行为来自Duck超类的具体实现，或是继承某个接口并子类自行实现而来。这两种做法都是依赖于“实现”，我们被实现绑得死死的，没有办法改变代码（除非写更多的代码）。

在我们的新设计中，鸭子的子类将使用接口（FlyBehavior与QuackBehavior）所表示的行为，所以实际的“实现”不会被绑死在鸭子的子类中。（换句话说，特定的具体行为编写在实现FlyBehavior与QuackBehavior的类中）。

问题：为什么非要把FlyBehavior设计成接口，而不使用抽象超类呢？使用抽象超类不就可以使用多态了吗？

其实，抽象超类型可以是“抽象类”或“接口”。

“针对接口编程”真正的意思是“针对超类型（supertype）编程”。

这里所谓的“接口”有多个含义，接口是一个“概念”，也是一种Java的interface构造。你可以在不涉及Java interface的情况下，“针对接口编程”，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。“针对超类型编程”这句话，可以更明确地说成“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型”。