[head first 设计模式] 第一章 策略模式

[head first 设计模式] 第一章 策略模式

让我们先从一个简单的鸭子模拟器开始讲起。

假设有个简单的鸭子模拟器，游戏中会出现各种鸭子，此系统的原始设计如下，设计了一个鸭子超类，并让各种鸭子继承此超类。

若此时我们有了一个新的需求，我们需要鸭子会飞，那么我们该如何修改代码呢？

最初，我们想在基类上加上fly方法，使得所有子类鸭子都拥有相应的fly方法。但这样错误产生了，即使是本不该会飞的橡皮鸭子也拥有了fly方法。

或许我们可以把橡皮鸭中的fly方法覆盖掉，但这样每次新加入的不会飞的新鸭子类型，难道都要额外覆盖一次fly方法吗？太麻烦了。

利用继承来提供duck的行为，会导致运行时的行为不容易改变，且改变容易牵一发动全身。

那么，利用接口如何?

若经常需要更新产品，那么每次覆盖fly简直是噩梦。那么，我们将fly单独写成一个接口，只有会飞的鸭子实现这个接口如何？

但这样其实重复的代码会变得非常多，造成fly代码无法复用，每个会飞的鸭子都要实现fly方法。

那么我们该如何解决这个问题？在使用设计模式之前，不妨先求索于OO原则！

软件开发中，什么是永恒真理？

唯一不变的是变化本身——约翰逊·斯宾塞

现在我们已经知道了继承无法很好的解决问题，因为鸭子的行为在子类中不断改变，并且有的行为子类不应该拥有。使用接口初看挺不错的，但继承接口无法达到代码的复用。这意味着，无论合适你需要修改某个行为，你必须向下追踪并在每一个定义此行为的类中修改它。

但还好，有一个OO设计原则正好适用于此种情况:

找出系统中可能需要变化之处，把他们独立出来，不要和那些不变化的代码堆在一起。

也就是把会变化的部分取出来，好让其他部分不会受此影响。

把会变化的部分取出来并封装，以后可以轻易地改动或扩充此部分，而不影响其他不需要变化的部分。

那么，现在是时候把鸭子的行为从Duck类中取出了。

分开变化和不会变化的部分

目前而言，除了fly()和quack()以外，duck类其他部分看起来不怎么变动，所以我们仅做些小改变。

为此，我们准备建立两组类，一个是和fly相关的，另一个和quack相关的，每一组类都实现各自的动作。

设计鸭子的行为

如何设计

那组实现飞行和叫声的类呢？我们希望一切能有弹性，并且能够将行为指定到鸭子的实例。并且可以让鸭子的行为动态的改变。

有了这些目标要实现，我们看第二个设计原则

针对接口编程，而不是针对实现编程。

从现在开始，鸭子的行为将被放在分开的类中，此类专门提供某行为接口的实现。这样，鸭子类就不再需要知道行为的具体细节。

这次鸭子类不会负责实现flying和quacking接口，而是由我们制造一组其他类专门实现flybehavior和quackbeavior，这就称为行为类，由行为类而不是duck类来实现行为接口。

这种做法和以往不同，以往是行为来自于duck超类的具体实现，或是继承某个接口并由子类自行实现而来。这两种方法都是依赖于实现，没法变更行为。

在我们的新设计中，鸭子的子类将使用接口所表示的行为，所以具体的实现不会被绑定在鸭子的子类中。

整合鸭子的行为

关键在于，鸭子会将飞行和叫声行为委托给其他对象处理。而不是由自己定义。

在Duck类中加入flyBehavior和quackBehavior变量，声明为接口类型。每个鸭子对象动态设置这些变量以在运行时引用正确的行为类型。

代码如下

public interface FlyBehavior {
    public void fly();
}

public interface QuackBehavior {
    public void quack();
}

public class FlyWithWings implements FlyBehavior{
    @Override
    public void fly() {
        System.out.println("I'm flying");
    }
}

public class FlyNoWay implements FlyBehavior{
    @Override
    public void fly() {
        System.out.println("I can't fly");
    }
}

public class Quack implements QuackBehavior{
    @Override
    public void quack() {
        System.out.println("quack!");
    }
}

public class MuteQuack implements QuackBehavior{
    @Override
    public void quack() {
        System.out.println("<<silence>>");
    }
}

public class Squeak implements QuackBehavior{

    @Override
    public void quack() {
        System.out.println("Squeak!");
    }
}

public abstract class Duck {
    protected FlyBehavior flyBehavior;
    protected  QuackBehavior quackBehavior;
    abstract void display();
    public void performFly()
    {
        flyBehavior.fly();
    }
    public void performQuack()
    {
        quackBehavior.quack();
    }
}

public class MallardDuck extends Duck{
    @Override
    public void display() {
        System.out.println("I'm a real mallard duck");
    }
    public MallardDuck(){
        flyBehavior = new FlyWithWings();
        quackBehavior  = new Quack();
    }
}

public class MiniDuckSimulator {
    public static void main(String[] args) {
        Duck mallardDuck = new MallardDuck();
        mallardDuck.performFly();
        mallardDuck.performQuack();
    }
}

动态设定行为

在鸭子子类中为两个behavior加入set方法，而不是在构造器中进行实例化。有了这个，我们就能在运行时随时改变鸭子的行为。

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

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

整体设计

现在我们来看看整体结构

我们不再把鸭子的行为说成是行为，而是一族算法。算法代表鸭子能做的事情。在本例中，我们鸭子的行为是组合来的，而不是继承来的。

我们得到第三个OO设计原则

多用组合，少用继承

学习完以上部分，我们正式定义策略模式