设计模式笔记（一）： 策略模式

当我们需要在系统中添加一些部分功能相同的类时，该怎么办呢？立刻能想到的是继承，将功能相同的代码抽离出来，放到基类中，之后有新的需求只需要继承这个基类即可。

继承带来的问题

但这里有一个问题，是否能完全确定将来的需求都具有基类中定义的功能呢？如果没有的话，继承基类的子类又包含基类的非私有方法，即子类“被迫添加”了一些他不想要的功能。当然，我们可以在子类中覆盖不想要的功能，只需在方法体什么都不做就行。（这只是掩耳盗铃，没有从根本上解决问题）但如果子类非常多，开发人员可能会忘记给某个子类覆盖不想要的方法，这可能会给整个系统带来非常严重的灾难。

不正确使用接口带来的问题

使用接口行不行呢？我认为是可以的，但是要注意如何正确使用接口。例如我们写了一个Flyable接口（表示可飞行的），基类没有实现可飞行的功能，那么如果子类需要添加可飞行的功能，就让子类实现这个接口，重写接口定义的方法即可。这样看起来挺不错的，但也有一个比较严重的问题。如果很多个子类都实现了Flyable接口，如果其中有大部分子类需要修改接口方法的具体实现，似乎我们只能一个类一个类的修改，这可能导致忘记修改某一个类的实现，最终导致系统功能异常。

如何正确使用接口

上面提到，使用接口是可行的，但是不正确使用的话可能会导致很严重的问题。那如何正确使用接口呢？我们先稍微分析一下上述的使用方法为什么是不正确的（或者说是不好的）。上面我们定义了一个Flyable接口，子类如果像要飞行功能的话，直接实现该接口即可，这样做的结果是具体实现非常散乱的分布在各个子类中，且极有可能出现代码重复。

所有，要正确的使用接口，我们可以从消除这样不良因素的角度入手。首先，既然代码可能会有重复，那么我们将其抽离出来形成一个实现了Flyable接口的类，这样该类就能表达出具有某种特定飞行行为的类。随后，在我们的基类中添加一个这个接口的字段，并添加setter方法，这样可以动态的调整飞行的具体实现。

说了那么多，都不如代码实在，下面是简单的代码实现：

抽象基类，Duck

public abstract class Duck {

    private FlyBehavior flyBehavior;
    private QuackBehavior quackBehavior;

    public abstract void display();

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

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

    public void swim() {
        System.out.println("swim");
    }

    public void setFlyBehavior(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }

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


}

Duck的子类

public class ModelDuck extends Duck {

    public ModelDuck() {
        setFlyBehavior(new NoFly());
        setQuackBehavior(new MuteQuack());
    }

    public void display() {
        System.out.println("i'm a model duck");
    }
}

FlyBehavior（表示Fly这个行为的接口）

public interface FlyBehavior {

    void fly();
}

QuackBehavior（表示Quack这个行为的接口）

public interface QuackBehavior {

    void quack();
}

QuackBehavior的一个实现类

public class Quack implements QuackBehavior {

    public void quack() {
        System.out.println("quack");
    }
}

FlyBehavior的一个实现类（表示无法飞行）

public class NoFly implements FlyBehavior {
    public void fly() {
        System.out.println("i'm can not fly");
    }
}

FlyBehavior的另一个实现类（表示带着火箭飞行）

public class FlyRocketPowered implements FlyBehavior {
    public void fly() {
        System.out.println("I'm flying with a rocket");
    }
}

测试类:

public class Main {

    public static void main(String[] args) {
        Duck duck = new ModelDuck();
        duck.display();
        duck.performFly();
        duck.performQuack();

        duck.setFlyBehavior(new FlyRocketPowered());
        duck.performFly();
        duck.performQuack();
    }
}

最终结果如下所示：

i'm a model duck
i'm can not fly
<< Silence >>
I'm flying with a rocket
<< Silence >>

从结果可以看出，我们可以动态的调整鸭子的行为，而且多个不同的鸭子不会包含大量的重复代码。

小结

这就是我们经常说的策略模式，现在可以给出其定义了：策略模式定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

在我们的代码中，FlyBehavior和QuackBehavior及其实现类分别是两个不同的算法族，每个算法族内部的算法之间可以相互替换，从而实现动态的调整，例如从NoFly调整成FlyRocketPowered，而且这样的调整不会影响使用该算法的用户。

本系列文章参考书籍是《Head First 设计模式》，文中代码示例出自书中。