大话设计模式——策略模式

一.开始之前

在进行讲解这个模式之前，我们首先想一个问题：我们现在有一个鸭子（duck）接口，工厂已经根据这个模型开始生产各种各样的鸭子实例，但是，上面突然提出需求，我们需要对于原有的鸭子添加新的行为或者功能；我们的处理办法呢？
可能很多人提出，可以在接口添加新的行为方法，子类进行实现；这时候，有一个橡皮鸭混在了里面，它没有任何表现行为；我们是不是还需要在子类进行定制开发；而且以后每一次维护都需要修改并且重复的修改；这对于我们程序员来说，可能不是一朝一夕的事（这谁顶得住啊）；
我们是不是可以想想一下，这些行为是不是有共同点，比如叫这个行为；要么鸭子是嘎嘎叫，要么不叫，或者发出一些特殊的声音，我们是不是可以把这些变化的行为提取出来？

二.设计模式的思想

其实，现实问题的解决方案有很多种，但是，便于我们后期的维护和开发，我们应当在开发之前就做到考虑全面；比如上述问题，用继承可以实现吗？显然是可以的；但是，设计模式的开闭原则呢？
我们做到了扩展；却做了大量的修改；这就不得不提一个中心思想：少用继承，多用组合！！！做到高内聚，低耦合。
所以，我们可以通过组合来提取鸭子的行为；我们定义一个行为接口；然后在各个实现类做到对行为的具体描述；然后在上下文对象（鸭子）来选择具体选择哪一个行为；

对于“叫”这个行为；我们将它视为一个抽象策略；除了“叫”；飞行也是一种策略（算法）；我们这里不做具体描述；对于抽象策略的具体实现就是：要么可以叫，要么不可以；而我们的抽象类鸭子拥有“叫”这个接口的引用；那么我们在它的子类会继承他的引用，并在构造方法中决定使用哪一种的具体策略。

三.代码实现

抽象类duck

public abstract class Duck {
    JiaoBehavior jiaoBehavior;
    FlyBehavior flyBehavior;
    public void swim(){
        System.out.println("所有鸭子都可以游泳");
    }
    public abstract void display();
    public void jiao(){
        jiaoBehavior.jiao();
    }
    public void fly(){
        flyBehavior.fly();
    }
}

jiao行为接口

public interface JiaoBehavior {
    void jiao();
}

可以jiao的具体实现策略

public class CanJiaoBehavior implements JiaoBehavior{
    @Override
    public void jiao() {
        System.out.println("可以叫的行为");
    }
}

不可以jiao的具体实现策略

public class CannotJiaoBehavior implements JiaoBehavior{
    @Override
    public void jiao() {
        System.out.println("bu可以叫的行为");
    }
}

duck类的子类

public class RedDuck extends Duck{
    public RedDuck(){
        jiaoBehavior = new CanJiaoBehavior();
        flyBehavior = new CanFlyBehavior();
    }
    @Override
    public void display() {
        System.out.println("这是一直红头鸭");
    }
}

我们在这里做到了选择具体使用哪种实现策略；但是有一定缺陷，在实例后的jiao的行为就没办法改变了；所以我们可以通过set方法实现动态修改；这里就不做论述了；

测试类

public class DuckTest {
    public static void main(String[] args){
        Duck d = new RedDuck();
        d.fly();
        d.swim();
        d.display();
        d.jiao();
    }
}

四.总结

如果你仔细思考策略模式的结构和功能的话，就会发现：如果没有上下文，策略模式就回到了最基本的接口和实现了，只要是面向接口编程，就能够享受到面向接口编程带来的好处，通过一个统一的策略接口来封装和分离各个具体的策略实现，无需关系具体的策略实现。

貌似没有上下文什么事，但是如果没有上下文的话，客户端就必须直接和具体的策略实现进行交互了，尤其是需要提供一些公共功能或者是存储一些状态的时候，会大大增加客户端使用的难度；引入上下文之后，这部分工作可以由上下文来完成，客户端只需要和上下文进行交互就可以了。这样可以让策略模式更具有整体性，客户端也更加的简单。

策略模式体现了开闭原则：策略模式把一系列的可变算法进行封装，从而定义了良好的程序结构，在出现新的算法的时候，可以很容易的将新的算法实现加入到已有的系统中，而已有的实现不需要修改。

策略模式体现了里氏替换原则：策略模式是一个扁平的结构，各个策略实现都是兄弟关系，实现了同一个接口或者继承了同一个抽象类。这样只要使用策略的客户端保持面向抽象编程，就可以动态的切换不同的策略实现以进行替换