我的Java设计模式-策略模式

摘要：孙膑心里一万个草泥马在奔腾，差点没噎死自己滚一边去，我们这盘跟他赛马开始，策略模式上场。在设计模式之禅中的提出通过策略枚举和反射机制对策略模式进行改良，膜拜了但是要添加或淘汰策略，还是得去对枚举进行修改，也不符合开闭原则。

今天给大家说说田忌赛马的故事。如有雷同，纯属巧合！话说在战国时期，群雄割据，硝烟四起，茶余饭后还是少不了娱乐活动的，其中赛马是最火爆的。一天，孙膑看到田忌像个死鸡似的就知道肯定赛马又输给了齐威王，立马抓住田忌去跟齐威王再赛一场。

孙膑：“小忌啊，哥哥看着你心疼啊，哥哥出对策帮你赢一盘如何？”。

田忌听到之后高兴得飞起，瞪大了两只金鱼眼“Really?只要能赢，我赴汤蹈火，以身相许又如何~”。

孙膑心里一万个草泥马在奔腾，差点没噎死自己“滚一边去，我们这盘跟他show hand！”赛马开始，策略模式上场。此处应该有bgm“让我们红尘作伴活得潇潇洒洒 策马奔腾共享人世繁华...呀啊呀啊，呀啊啊啊啊啊啊~”

  定义一组算法，将每一个算法封装起来，从而使它们可以相互切换。

  1）一组算法，那就是不同的策略。

  2）这组算法都实现了相同的接口或者继承相同的抽象类，所以可以相互切换。

策略模式涉及到的角色有三个：

  - 封装角色：上层访问策略的入口，它持有抽象策略角色的引用。

  - 抽象策略角色：提供接口或者抽象类，定义策略组必须拥有的方法和属性。

  - 具体策略角色：实现抽象策略，定义具体的算法逻辑。

在跟齐威王比赛之前来分析下之前输掉比赛的“策略”，首先来看封装角色，代码如下：

public class Context {

    private Strategy strategy;

    /**
     * 传进的是一个具体的策略实例
     * @param strategy
     */
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    /**
     * 调用策略
     */
    public void contextInterface() {
        strategy.algorithmLogic();
    }

}

Context持有Strategy的引用，并且提供了调用策略的方法，很清晰。

再来抽象策略角色，定义了策略组的方法，代码如下：

public interface Strategy {

    public void algorithmLogic();

}

输掉比赛的“策略”也是一种策略，是具体策略角色类，来看代码：

public class ConcreteStrategyA implements Strategy{

    @Override
    public void algorithmLogic() {
        // 具体的算法逻辑（输了比赛）
        System.out.println("第一场：上等马vs上等马  第二场：中等马vs中等马  第三场：下等马vs下等马  赛果：输！");
    }
}

看到这里，孙膑一阵无语，惨不忍睹也得看结果的，客户端代码如下：

public class Client {

    public static void main(String[] args) {
        // 操控比赛，这场要输
        Context context = new Context(new ConcreteStrategyA());
        context.contextInterface();
    }
}

两句代码，传入具体策略对象，调用策略入口方法，运行结果如下:

第一场：上等马vs上等马  第二场：中等马vs中等马  第三场：下等马vs下等马  赛果：输！

田忌跟孙膑说：“膑哥，我怕！”，孙膑：“不用怕，哥哥在！”。

田忌找到齐威王“大王，我们再...再再来一盘，输了请吃饭”

瞅瞅孙膑出的策略，一睹军事家的风采，“赢”的具体策略类代码如下：

public class ConcreteStrategyB implements Strategy{
    @Override
    public void algorithmLogic() {
        // 赢
        System.out.println("第一场：下等马vs上等马  第二场：上等马vs中等马  第三场：中等马vs下等马  赛果：赢！");
    }
}

再来看客户端的代码：

public class Client {
    public static void main(String[] args) {

        // 操控比赛，这场要赢，哈哈哈
        Context context = new Context(new ConcreteStrategyB());
        context.contextInterface();
    }
}

运行结果如下：

第一场：下等马vs上等马  第二场：上等马vs中等马  第三场：中等马vs下等马  赛果：赢！

田忌拍烂手掌，重要的是今天晚饭有着落了，还要对膑哥哥以身相许的......

1）良好的扩展性。增加一种策略，只要实现接口，写上具体逻辑就可以了。当旧策略不需要时，直接剔除就行。

2）良好的封装性。策略的入口封装在Context封装类中，客户端只要知道使用哪种策略就传哪种策略对象就可以了。

3）避免了像简单工厂模式这样的多重条件判断。

1）客户端必须了解策略组的各个策略，并且决定使用哪一个策略，也就是各个策略需要暴露给客户端。

2）如果策略增多，策略类的数量就会增加。

上面说到策略模式有一个缺点，就是所有的策略都必须暴露出去，让客户端自行选择策略使用。现在来改善这一缺陷，而改善这个缺陷需要跟简单工厂模式结合混编，继续往下看。

当然，军事家孙膑也会想到这一点，怎么可能会把自己的套路全都暴露给别人呢，那还怎么玩是吧。不过，历史上并没有说孙膑改善了这点，现在是我来改善这个缺陷，哈哈哈~

思考一个问题，策略暴露了，改善就是把策略隐藏起来，而工厂模式就有这个效果，客户端不需要知道策略具体是什么，只知道结果就好。OK，那么我们可以使用工厂模式把策略当做产品生成吗？答案是肯定的。策略模式的入口就在Context封装类，可以从这个角色做手脚。先看代码：

public class Context {

    private Strategy strategy;

    // 把创建策略放在封装角色内，客户端只需要知道结果
    public void factory(String strategyType) {
        if (strategyType.equals("WIN")) {
            strategy = new ConcreteStrategyB();
        } else if (strategyType.equals("LOSE")) {
            strategy = new ConcreteStrategyA();
        }
    }

    /**
     * 调用策略
     */
    public void contextInterface() {
        strategy.algorithmLogic();
    }
}

代码很简单，增加了factory的方法，这个方法作用就是创建策略对象。这样，客户端就不需要去理解具体的策略，只需知道具体策略的结果就好。看看客户端代码：

public class Client {

    public static void main(String[] args) {
        Context context = new Context();
        context.factory("LOSE");
        context.contextInterface();
    }
}

注意策略模式和工厂方法模式的区别，在前面工厂方法模式中有说到，这里就不再阐述。策略模式本身也相对比较简单，重点在它的扩展以及其它模式的对比，分析各自的优缺点。来看看策略工厂这样的模式存在缺点吗？很明显，如果需要添加或者淘汰一种策略，Context就必须修改，这并不符合开闭原则。在《设计模式之禅》中的提出通过策略枚举和反射机制对策略模式进行改良，膜拜了~但是要添加或淘汰策略，还是得去对枚举进行修改，也不符合开闭原则。根据自己项目情况，选择最适合自己项目的模式。下一篇是责任链模式，欢迎继续关注，goodbye！

设计模式Java源码GitHub下载：https://github.com/jetLee92/DesignPattern