策略模式

一款鸭子模拟应用，有多种鸭子，绿色头的、红色头的，会叫会飞会游泳多种行为。要你设计出相应的类要怎么实现，这个简单，看下面。

上面的例子看起来设计的不错，却经不起需求的变化。
变化1：
假设现在来了一只橡皮鸭，它能伏在水面勉强算会游泳，捏一下也会叫，但是它不会飞，再继续采用上面的方式就不可行了。你可能会想到，让橡皮鸭继承Duck并覆盖fly()方法，这个方法什么也不做，这样橡皮鸭就不会飞了。这样貌似也可以，只要修改一点就能完成。
变化2：
那么再假设这些鸭子叫的声音不同，鸭子呱呱叫、橡皮鸭吱吱叫，要解决这个变化，你可能会想到继承Duck后，不同的鸭子覆盖quack方法，实现不同叫声。

经过这两个变化后，类图变成了这样。

现在你还会觉得这种设计合理吗？很明显，这种设计不合理。那么我们该怎么设计呢？

根据面向对象设计原则，封装变化。 我们需要把这些变化的部分封装起来，让其他本应该不变的部分不受影响。定义quack和fly定义为两个行为类，而Duck类持有这两个类的属性。根据针对接口编程原则，我们需要把quack和fly定义为接口，对应不同的行为，实现如下。

其中Duck的代码变成这样：

/**
 * Created by LiuJinan on 2017/6/11.
 */
public class Duck {

    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;

    public void swim() {
        //游泳
    }

    public void performFly() {
        flyBehavior.fly();
    }

    public void performQuack() {
        quackBehavior.quack();
    }

    public void display() {

    }
    //加上set方法，可以动态改变行为
    public void setFlyBehavior(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }

    public void setQuackBehavior(QuackBehavior quackBehavior) {
        this.quackBehavior = quackBehavior;
    }
}

最终类图：

根据最后的类图，假设现在我们再添加一个小鸭子的类，小鸭子会游泳会呱呱叫，但是还没学会飞，此时你会发现，原来的代码完全不需要改动。

---

从文章标题就知道上面的例子实际使用的是策略模式，定义如下。

策略模式的定义：

该模式定义了一系列的算.法，并将每一个算.法封装起来，而且使它们还可以相互替换。策略模式让算.法独立于使用它的客户而独立变化。

结合我们此次的例子，其实很好理解。我们看最终类图，图中有封装叫行为和封装飞行为，这两种行为对应定义中的一系列算.法，客户就对应各种鸭子。我们在定义不同的鸭子时会为它选择不同的行为，鸭子和行为是独立的，符合策略模式的定义。