当我们需要在系统中添加一些部分功能相同的类时，该怎么办呢？立刻能想到的是继承，将功能相同的代码抽离出来，放到基类中，之后有新的需求只需要继承这个基类即可。
继承带来的问题
但这里有一个问题，是否能完全确定将来的需求都具有基类中定义的功能呢？如果没有的话，继承基类的子类又包含基类的非私有方法，即子类“被迫添加”了一些他不想要的功能。当然，我们可以在子类中覆盖不想要的功能，只需在方法体什么都不做就行。（这只是掩耳盗铃，没有从根本上解决问题）但如果子类非常多，开发人员可能会忘记给某个子类覆盖不想要的方法，这可能会给整个系统带来非常严重的灾难。
不正确使用接口带来的问题
使用接口行不行呢？我认为是可以的，但是要注意如何正确使用接口。例如我们写了一个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 设计模式》，文中代码示例出自书中。