策略模式（java）

引

　　GOF 《设计模式：可复用面向对象软件设计的基础》中的模式，应当算是模式归纳的鼻祖（并非他们最早发现/使用了模式，而是将已有的模式进行了整合归纳），而我们现在对于模式的学习基本上都是基于Gof的设计模式。今天主要说说行为型模式中的一个：策略模式。

模式定义

　　意图：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

 

　　动机：

• 　　客户程序如果直接包含策略算法代码，将会变得很复杂。（策略算法本身足够复杂）
• 　　不同的时候需要不同的算法　　　（if....else....）

模式类图

阐述与讨论

　　策略模式是我们在开发中常用的模式之一。网上关于策略模式也有很多介绍，这里再次提出，是期望给出“正规”的模式，在我初学设计模式时，也经常会被搞得不知所云，众说纷纭还给出代码，但几乎都不太一样，我也曾被策略模式搞得迷糊（主要是context），因此再次找出GOF原本进行分析- -

　　最常见的疑惑问题：策略模式和简单工厂模式进行比较。两者区别还是比较大的，不管是从语义还是实现上。

　　下面给出简单工厂的类图（GOF模式中没有简单工厂---只有抽象工厂和工厂方法）：

　　

　　对比简单工厂和策略模式类图很容易发现区别： 工厂（Factory）是依赖Product接口，同时依赖于具体产品（ProductA和ProductB），而策略模式中，Context是包含了Stategy接口，同时并不依赖具体的策略类。

通过代码很容易就可以看出区别:

　　策略模式代码：

package strategydemo;
/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 策略上下文
 */
public class Context {
    // 包含关系
    private Strategy strategy ; 
    // 这个类中包含具体策略需要的其他参数，必要时可以将自己传递给策略类（GOF)
    public Context(Strategy strategy){
        this.strategy = strategy;
    }
    
    public int get(){
        return this.strategy.algorithm();
    }
}

 

package strategydemo;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 策略接口
 */
public class StrategyB implements Strategy {
    @Override
    public int algorithm() {
        // 这里的逻辑应当比较复杂，否则没有必要使用策略类
        // 仅作说明
        return 0;
    }

}

package strategydemo;

public class StrategyA implements Strategy {
    @Override
    public int algorithm() {
        // 这里的逻辑应当比较复杂，否则没有必要使用策略类
        // 仅作说明
        return 1;
    }

}

package strategydemo;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 策略接口
 */
public class StrategyB implements Strategy {
    @Override
    public int algorithm() {
        // 这里的逻辑应当比较复杂，否则没有必要使用策略类
        // 仅作说明
        return 0;
    }

}

package strategydemo;
/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 客户端
 */
public class Main {
    public static void main(String[] args) {
        // 具体策略类
        Strategy a = new StrategyA();
        //Context
        Context ctx = new Context(a);
        
        System.out.println(ctx.get());
    }
}

代码结构和名称大体按照策略类图所给出的。可以看到客户端是“知道”（或者说依赖于）具体策略类的。而Context对于具体策略类并不存在任何依赖（无知），只是“包含”（类中属性）了策略接口。

下面给出简单工厂实现：

package simplefactory;

/**
 * @author : xiaolu 2018年2月6日
 * @todo :产品接口
 */
public interface Product {
    // ...... 工厂模式中，工厂主要用于产生产品，并不涉及产品的操作，因此此处省略具体产品的操作
}

package simplefactory;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 产品A
 */
public class ProductA implements Product {

}

package simplefactory;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 产品B
 */
public class ProductB implements Product {

}

package simplefactory;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 简单工厂
 */
public class Factory {
    // 返回值为产品接口
    public Product get(int i) {
        if (i == 0) {
            // 返回具体的产品（有依赖）
            return new ProductA();
        } else if (i == 1) {
            // 返回具体的产品（有依赖）
            return new ProductB();
        } else {
            throw new RuntimeException("不支持");
        }
    }
}

package simplefactory;

/**
 * @author : xiaolu 2018年2月6日
 * @todo   : 客户端
 */
public class Main {
    public static void main(String[] args) {
        Factory f = new Factory();
        // 客户端不知道（不依赖）具体产品
        Product p = f.get(1);
        // 执行p的操作
    }
}

对比类图和代码实现，应该从结构上很容易区分两者。更重要的是：策略模式是行为型模式，而工厂模式是创建型模式！通俗的说，工厂模式只负责产生“按你所需”的产品，至于你如何使用，工厂是无知的（这也是我为什么没有在产品接口中定义方法，因为不固定）。而策略模式中，具体的策略类是客户端“知道”的（这也是是否需要直接使用策略模式的一个选择【也可以规避它-策略+工厂】），而Context则负责“转发”（只是转发吗？）这里不妨想想，为什么需要Context，如果没有Context会如何呢？如果没有：

Strategy strategy = new StrategyA();

strategy.algorithm();

好像还反而简单了？Context是Strategy和Main(客户端）之间的一个间接层，可以用来封装需要传递给Strategy的数据结构和参数。

 

　　相对于普通的多态结构，策略模式强调的是【算法】的可相互替代性。再次强调：如果具体策略类并不复杂就不要用策略模式（自找烦恼）。而策略类的一个弊端：客户端类需要“知道”具体策略类------可以通过加一个工厂解决。简单工厂的意义是什么呢？ 符合SRP，单一职能，降低耦合 ，还有一个作用---------转换。大部分的if....else代码我们并不能规避，只是从“这里”移到了“那里”，好处是代码更明确，更清晰，更容易扩展，而简单工厂做这种转换非常的合适。使用简单工厂+策略模式的类图如下：

　　（上面的线条有点多？是的，我画出了所有的依赖关系）。在这里，可以看到Client端不再依赖于具体的策略类（策略A/B）,.而是依赖于工厂，而工厂在这里可以做出转换。假设测试都是关于打折的，现在要求是3-9月份，使用打折策略A（打8折），其余时间采用B策略（打9折）......那么就存在一种映射关系：

　　3-9月份--------------策略A

       1-2和10-12月份---策略B

　　在工厂中就是进行进行这种转换的最好地方（什么？工厂中存在了if.....else.....嗯是这样的【使用Map来替代，换汤没换药】），同时工厂仅做了一件事，而没有将映射策略放在客户端（客户端往往还有很多其它的处理，并非说放在客户端不能实现，只是本身客户端就很复杂了，不想再给它增加复杂性），到这里基本上可以结束，但是有人说了，不符合OCP（开闭原则），有新的映射到来呢，还需要修改工厂，于是简单工厂会升级为工厂方法.......拒绝模式的诱惑和过度优化，我个人理解：代码写的自己觉得舒服，容易阅读就好，过犹不及！不要一看到if.....else就深恶痛绝---然后去考虑某个（例如策略）模式去替代，这样做之前，请多多三思。在写代码过程中必须意识到复杂性和灵活性大多时候成正比（相对有模式的引入，没有模式引入的代码更为简单-----如果是很习惯模式可能除外，但是请考虑新手）。

　　最后再提一个经常误导我的：有人将Factory和Context进行了“糅合”（就是Context直接依赖了具体策略，看图吧）

　　这不是和简单工厂的类图“一模一样”吗？是的，因为这个原因，所以才会将工厂和策略模式搬出来做对比！这种用法不做好坏评论，从GOF来说偏离了模式本意（所以看到策略这种实现，不要觉得疑惑【这是人为的做了修改-----不过改的好与不好......呵呵】），更像是工厂的形，“策略”的神。个人感觉：在简单的时候（Context用来为Strategy准备参数，如果只是很简单的情况---转发/委托，我觉得这种方式也无不可------相对于上面的工厂+策略，确实简单了很多），但是如果Context本身就很复杂，我个人还是建议还原为工厂+策略。只是我们在看到这种很“亲密”的且称为策略的模式时，不要被迷惑和搞混就好。