Java设计模式——策略模式

Posted 2021-05-18 chun_soft

1、简介

策略模式(Strategy Pattern)是一种比较简单的模式，也叫做政策模式(Policy Pattern)。其定义如下:
Define a family of algorithms, encapsulate each one, and make them interchangeable.(定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。)

我们看看策略模式的通用类图。

策略模式使用的就是面向对象的继承和多态机制，非常容易理解和掌握，我们再来看看策略模式的三个角色:

• Context封装角色

它也叫做上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。

• Strategy抽象策略角色

策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。

• ConcreteStrategy具体策略角色

实现抽象策略中的操作，该类含有具体的算法。

2、推荐实现案例

再来看策略模式的通用源码，非常简单。

• （1）抽象的策略角色

先看抽象策略角色，它是一个非常普通的接口，在我们的项目中就是一个普通得不能再普通的接口了，定义一个或多个具体的算法，如代码所示。

// 策略模式的运算法则
public interface Strategy { 
    public void doSomething();
}

• （2）具体策略角色

具体策略也是非常普通的一个实现类，只要实现接口中的方法就可以，如代码所示。

public class ConcreteStrategy1 implements Strategy { 
    public void doSomething() {
        System.out.println("具体策略1的运算法则"); 
    }
}

public class ConcreteStrategy2 implements Strategy {
    public void doSomething() { 
        System.out.println("具体策略2的运算法则");
    } 
}

• （3）封装角色

策略模式的重点就是封装角色，它是借用了代理模式的思路，大家可以想想，它和代理模式有什么差别，差别就是策略模式的封装角色和被封装的策略类不用是同一个接口，如果同一个接口那就成为了代理模式。我们来看封装角色，如代码所示。

// 抽象策略
public class Context { 
    
    // 构造函数设置具体策略
    private Strategy strategy = null; 
    
    public Context(Strategy _strategy){
        this.strategy = _strategy;
    }
    
    //封装后的策略方法
    public void doAnythinig(){
        this.strategy.doSomething();
    } 
}

• （4）高层模块

高层模块的调用非常简单，知道要用哪个策略，产生出它的对象，然后放到封装角色中就完成任务了，如代码清单所示。

public class Client {
    public static void main(String[] args) {
        //声明一个具体的策略
        Strategy strategy = new ConcreteStrategy1(); //声明上下文对象
        Context context = new Context(strategy); //执行封装后的方法
        context.doAnythinig();
    } 
}

策略模式就是这么简单，它就是采用了面向对象的继承和多态机制，其他没什么玄机。想想看，你真实的业务环境有这么简单吗?一个类实现多个接口很正常，你要有火眼金睛看清楚哪个接口是抽象策略接口，哪些是和策略模式没有任何关系，这就是你作为系统分析师的价值所在。

3、优缺点

3.1 优点

• 算法可以自由切换
  这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。

• 避免使用多重条件判断
  如果没有策略模式，我们想想看会是什么样子?一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢?使用多重的条件语句?多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。

• 扩展性良好
  这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。

3.2 缺点

• 策略类数量增多
  每一个策略都是一个类，复用的可能性很小，类数量增多。

• 所有的策略类都需要对外暴露
  上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢?那要你的封装类还有什么意义?这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷，如工厂方法模式、代理模式或享元模式。

4、应用场景

• 多个类只有在算法或行为上稍有不同的场景。

• 算法需要自由切换的场景。
  例如，算法的选择是由使用者决定的，或者算法始终在进化，特别是一些站在技术前沿的行业，连业务专家都无法给你保证这样的系统规则能够存在多长时间，在这种情况下策略模式是你最好的助手。

• 需要屏蔽算法规则的场景。
  现在的科技发展得很快，人脑的记忆是有限的(就目前来说是有限的)，太多的算法你只要知道一个名字就可以了，传递相关的数字进来，反馈一个运算结果，万事大吉。

5、注意事项

如果系统中的一个策略家族的具体策略数量超过4个，则需要考虑使用混合模式，解决策略类膨胀和对外暴露的问题，否则日后的系统维护就会成为一个烫手山芋，谁都不想接。

6、拓展

先给出一道小学的题目:输入3个参数，进行加减法运算，参数中两个是int型的，剩下的一个参数是String型的，只有“+”、“-”两个符号可以选择，不要考虑什么复杂的校验，我们做的是白箱测试，输入的就是标准的int类型和合规的String类型。

有非常多的实现方式，我今天来说四种。

• （1）最直接的加减法
  先说第一种，写一个类，然后进行加减法运 、算，类图也不用画了，太简单了，如代码清单所示。

public class Calculator {
    // 加符号
    private final static String ADD_SYMBOL = "+";
    // 减符号
    private final static String SUB_SYMBOL = "-";
    
    public int exec(int a,int b,String symbol){
        int result =0; 
        if(symbol.equals(ADD_SYMBOL)) {
            result = this.add(a, b); 
        } else if(symbol.equals(SUB_SYMBOL)){
            result = this.sub(a, b); 
        }
        return result;
    }
    
    //加法运算
    private int add(int a,int b){
        return a+b;
    }
    
    //减法运算
    private int sub(int a, int b){
        return a-b;
    } 
}

这个方案是非常简单的，能够解决问题，我相信这是大家最容易想到的方案，我们不评论这个方案的优劣，等把四个方案全部讲完了，你自己就会发现孰优孰劣。

• (2)简化算法

public class Calculator {
    // 加符号
    private final static String ADD_SYMBOL = "+";
    // 减符号
    private final static String SUB_SYMBOL = "-";
    public int exec(int a, int b, String symbol) {
        return symbol.equals(ADD_SYMBOL)?a+b:a-b;
    }
}

这也非常简单，就是一个三目运算符，确实简化了很多。有缺陷先别管，我们主要讲设
计，你在实际项目应用中要处理该程序中的缺陷。

• (3)策略模式

我们再来思考第三个方案，本文介绍策略模式，那把策略模式应用到该需求是不是很合适啊?是的，非常合适!加减法就是一个具体的策略，非常简单，省略类图，直接看源码，我们先来看抽象策略，定义每个策略必须实现的方法。

引入策略模式

public interface Calculator {
    public int exec(int a, int b);
}

抽象策略定义了一个唯一的方法来执行运算。至于具体执行的是加法还是减法，运算时由上下文角色决定。我们再来看两个具体的策略，如代码所示。

具体策略

public class Add implements Calculator { //加法运算
    public int exec(int a, int b) {
        return a+b;
    }
}

public class Sub implements Calculator { //减法运算
    public int exec(int a, int b) { 
        return a-b;
    } 
}

封装角色的责任是保证策略时可以相互替换，如代码所示。

public class Context {
    private Calculator cal = null; 
    
    public Context(Calculator _cal) {
        this.cal = _cal;
    }
    
    public int exec(int a, int b){
        return this.cal.exec(a, b);
    } 
}

上下文类负责把策略封装起来，具体 怎么自由地切换策略则是由高层模块负责声明的，如代码所示。

public class Client { 
    //加符号
    public final static String ADD_SYMBOL = "+"; 
    //减符号
    public final static String SUB_SYMBOL = "-"; 
    
    public static void main(String[] args) {
        //输入的两个参数是数字
        int a = Integer.parseInt(args[0]);
        String symbol = args[1]; //符号
        int b = Integer.parseInt(args[2]); 
        System.out.println("输入的参数为:"+Arrays.toString(args)); 
        //上下文
        Context context = null;
        //判断初始化哪一个策略
        if(symbol.equals(ADD_SYMBOL)){
            context = new Context(new Add()); 
        } else if(symbol.equals(SUB_SYMBOL)) {
            context = new Context(new Sub());
        } 
        System.out.println("运行结果为:" + a + symbol + b + "=" + context.exec(a,b);
    } 
}

运行结果与方案一相同。我们想想看，在该策略模式的一个具体应用中，我们使用 Context准备了一组算法(加法和减法)，并封装了起来，具体使用哪一个策略(加法还是减法)则由上层模块声明，这样扩展性非常好。

现在只剩最后一个方案了，它就是——策略枚举!

7、最佳实践-策略枚举

public enum CalculatorEnum {
    // 加法运算
    ADD("+") {
        @Override
        public int exec(int a, int b) {

            return a + b;
        }
    },

    // 减法运算
    SUB("-") {
        @Override
        public int exec(int a, int b) {

            return a - b;
        }

    };

    String value = "";

    CalculatorEnum(String value) {

        this.value = value;
    }

    /**
     * 获得枚举成员的值
     * @return 值
     */
    public String getValue() {

        return this.value;
    }

    // 声明一个抽象函数
    public abstract int exec(int a, int b);
}

先想一想它的名字，为什么叫做策略枚举?枚举没有问题，它就是一个Enum类型，那为什么又叫做策略呢?

找找看能不能找到策略的影子在里面?是的，我们定义了一个抽象的方法exec，然后在每个枚举成员中进行了实现，如果不实现会怎么样呢?

你试试看看，不实现该方法就不能编译，现在是不是清楚了?把原有定义在抽象策略中的方法移植到枚举中，每个枚举成员就成为一个具体策略。简单吧，总结一下，策略枚举定义如下:

• 它是一个枚举。
• 它是一个浓缩了的策略模式的枚举。

当然，读者可能要反思了，我使用内置类也可以实现相同的功能，写一个Context类，然后把抽象策略、具体策略都内置进去，不就可以解决问题了，是的，可以解决，但是扩展性如何?可读性如何?代码是让人读的，然后才是让机器执行，别把顺序搞反了!

我们继续完善方案四，场景类稍有改动，如代码所示。

public class Client {
    public static void main(String[] args) {
        // 输入的两个参数是数字
        int a = Integer.parseInt(args[0]);
        String symbol = args[1]; 
        //符号
        int b = Integer.parseInt(args[2]); 
        System.out.println("输入的参数为:" + Arrays.toString(args));
        System.out.println("运行结果为:" + a + symbol + b + "=" + Calculator.ADD.exec(a, b);
    } 
}

运行结果与方案一相同。看这个场景类，代码量非常少，而且还有一个显著的优点:真
实地面向对象，看看这条语句:

Calculator.ADD.exec(a, b)

是不是类似于“拿出计算器(Calculator)，对a和b进行加法运算(ADD)，并立刻执行
(exec)”，这与我们日常接触逻辑是不是非常相似，这也正是架构师要担当的职责!

注意：策略枚举是一个非常优秀和方便的模式，但是它受枚举类型的限制，每个枚举项都是public、final、static的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。