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

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

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

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

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

一、策略模式

定义

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

特点

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

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

UML

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

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

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

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

二、实战

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

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