设计模式之策略模式

1、定义：

定义一系列算法，将每个算法封装到具有公共接口的一系列策略类中，从而使它们可以相互替换，并让算法可以在不影响到客户端的情况下发生变化。

简单来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”

2、模式原理

3、实例讲解

书中以一个例子来开展策略模式，方便理解。
1：模拟鸭子游戏：游戏中会出现各种鸭子，一边游泳戏水，一边呱呱叫，设计一个鸭子超类，并让各种鸭子继承此超类。
所有的鸭子都会呱呱叫（Quack）也会游泳（Swim）所以由超类负责处理这部分的实现代码。每一种鸭子的外观都不同，所以display()方法是抽象的。

class abstract Duck{

    public void quack(){};
    public void swim(){};
    public abstract void display();
}

class MallardDuck extends Duck{
    @Override
    public void display(){
    //外观是绿头
    }
}

class RedheadDuck extends Duck{
    @Override
    public void display(){
    //外观是红头
    }
}

主管之后希望鸭子能飞。
设想：只需要在Duck类中加上fly()方法，然后让所有鸭子都会继承fly().

class abstract Duck{ 
    public void quack(){}; 
    public void swim(){}; 
    public void fly(){}; 
    public abstract void display(); 
}

但是，可怕的问题发生了：发现很多的“橡皮鸭子”在天上飞。所以并非Duck所有的子类都会飞。像橡皮鸭子这样没有生命的鸭子。
当涉及“维护”时，为了“复用”目的而使用继承，结局并不完美。
这时候想到继承。可以把橡皮鸭类中的fly()方法覆盖掉。

class RubberDuck extends Duck{ 
    @Override
    public void quack(){ 
    } 
    @Override 
    public void display(){ 
    //橡皮鸭
    }
    @Override 
    //覆盖，变成什么事都不做 
    } 
}

认识到继承可能不是答案，每当有新的鸭子子类出现，他就要被迫检查并可能需要覆盖fly()和quark()……所以我们需要一个更清晰的方法，让“某些”鸭子类型可飞或可叫。
我们可以把fly()从超类中取出来，放进一个“Flyable接口”中，这么一来，只有会飞的鸭子才实现此接口，同样的方式，也可以设计一个“Quackable接口”。

interface Flyable{ 
    public void fly();
 }

interface Quackable{ 
    public void quack();
 }

 class Abstract Duck{ 
    public void swim();
    public void abstract display();
 }

class MallardDuck extends Duck implements Flyable,Quackable{    
    @Override 
    public void display() { } 
    @Override
    public void fly() { } 
    @Override 
    public void quack(){ } 
}

你会发现虽然Flyable与Quackable可以解决“一部分”问题，但是却造成代码无法复用，这只能算是从一个噩梦跳进另一个噩梦。甚至，在会飞的鸭子中，飞行的动作可能还用多种变化。

现在我们知道使用继承并不能很好地解决问题，因为鸭子的行为在子类里不断地改变，并且让所有的子类都有这些行为是不恰当的，Flyable与Quackable接口一开始似乎还挺不错，但是java接口不具有实现代码，所以继承接口无法达到代码的复用。这就意味着：无论何时你需要修改某个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误。

幸运的是，有一个设计原则，恰好适用于此状况：

第一个设计原则：
找出应用中可能需要变化之处，把它们独立起来，不要和那些不需要变化的代码混在一起。

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

第二个设计原则：
针对接口编程，而不是针对实现编程。

interface FlyBehavior{ 
    void fly(); 
} 
class FlyWithWings implements FlyBehavior
{ 
    @Override 
    public void fly() { 
    //实现鸭子的飞行动作 
    } 
} 
class FlyNoWay implements FlyBehavior
{ 
    @Override 
    public void fly() { 
    //什么都不做，不会飞 
    }
 }

利用接口代表每个行为，FlyBehavior与QuackBehavior，而行为的每个实现都将实现其中的一个接口。

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

我们的新设计中，鸭子的子类将使用接口（FlyBehavior与QuackBehavior）所表的行为，所以实际的“实现”不会被绑死在鸭子的子类中。

这里有一个问题：为什么非要把FlyBehavior设计成接口，为何不适用抽象超类，这样不就可以使用多态了吗？
“针对接口编程”真正的意思是“针对超类型编程”。

这里所谓的“接口”有多个含义，接口是一个“概念”，也是一种java的interface构造。“针对接口编程”，关键就在多态，利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。
实现鸭子的行为

interface QuackBehavior{ 
    void quack(); 
} 
class Quack implements QuackBehavior{ 
    @Override 
    public void quack() 
    { 
        //实现鸭子呱呱叫 
    } 
} 

class Squeak implements QuackBehavior{
     @Override 
     public void quack() {
         //橡皮鸭吱吱叫
    }
} 

class MuteQuack implements QuackBehavior{ 
    @Override
     public void quack() {
         //什么都不做，不会叫
    } 
}

这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。
而我们可以新增一些行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类。

此时的鸭子类可以整合为：

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

实现该类：

class MallardDuck extends Duck
{
    public MallardDuck(){
        quackBehavior=new Quack(); //实现了具体的方法
        flyBehavior=new FlyWithWings(); //实现了具体的方法
    }
    @Override 
    public void display()
     { 
         System.out.println("I'm a real Mallard duck"); 
     }
     //可以新增两个setter方法，初始化Beavior，在类外部可以使用该方法
     public void setFlyBehavior(FlyBehavior fb){ 
         flyBehavior=fb; 
     } 
     public void setQuackBehavior(QuackBehavior qb){ 
        quackBehavior=qb; 
     }
}

4、优缺点

在全面解析完后，我来分析下其优缺点：

4.1优点

1. 策略类之间可以自由切换 由于策略类都实现同一个接口，所以使它们之间可以自由切换， 易于扩展 。
2. 增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则“
3. 避免使用多重条件选择语句（if-else），充分体现面向对象设计思想。

4.2 缺点

1. 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
2. 策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。