策略模式

Published on 2016 - 07 - 17

策略模式的定义

策略模式(Strategy Pattern)是一种比较简单的模式,也叫做政策模式(Policy Pattern)。其定义如下:

Define a family of algorithms,encapsulate each one,and make them interchangeable.(定义一组算法,将每个算法都封装起来,并且使它们之间可以互换。)

我们看看策略模式的通用类图,如图3所示。

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

  • Context封装角色

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

  • Strategy抽象策略角色

策略、算法家族的抽象,通常为接口,定义每个策略或算法必须具有的方法和属性。各位看官可能要问了,类图中的AlgorithmInterface是什么意思,嘿嘿,algorithm是“运算法则”的意思,结合起来意思就明白了吧。

  • ConcreteStrategy具体策略角色

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

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

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

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

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

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

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

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

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

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

策略模式的应用

策略模式的优点

  • 算法可以自由切换

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

  • 避免使用多重条件判断

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

  • 扩展性良好

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

策略模式的缺点

  • 策略类数量增多

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

  • 所有的策略类都需要对外暴露

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

策略模式的使用场景

  • 多个类只有在算法或行为上稍有不同的场景。
  • 算法需要自由切换的场景。

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

  • 需要屏蔽算法规则的场景。

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

策略模式的注意事项

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

策略模式的扩展

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

有非常多的实现方式,我今天来说四种。先说第一种,写一个类,然后进行加减法运算,类图也不用画了,太简单了,如代码清单11所示。

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;
     }
}

算法太简单了,每个程序员都会写。再写一个场景类如12所示。

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));
             //生成一个运算器
             Calculator cal = new Calculator();
             System.out.println("运行结果为:"+a + symbol + b + "=" + cal.exec(a, b, symbol));
     }
}

输入3个参数,分别是100 + 200,运行结果如下所示:

输入的参数为:[100, +, 200]
运行结果为:100+200=300

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

我们再来看第二个方案,Calculator类太嗦了,简化算法如代码清单13所示。

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;
     }
}

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

该方案的场景类与方案一相同,如代码清单12所示,运行结果也相同,不再赘述。

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

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

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

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;
     }
}

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

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

代码都非常简单,该部分就不再增加注释信息了。上下文类负责把策略封装起来,具体怎么自由地切换策略则是由高层模块负责声明的,如代码清单17所示。

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,symbol));
     }
}

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

现在只剩最后一个方案了,一般最后出场的都是重量级的人物,压场嘛!那就请出我们最后一个重量级角色,音乐响起,一个黑影站定舞台中央,所有灯光突然聚焦,主角缓缓抬起头,它就是——策略枚举!我们来看看其真实实力,如代码清单18所示。

public enum Calculator {
     //加法运算
     ADD("+"){
             public int exec(int a,int b){
                    return a+b;
             }
     },
     //减法运算
    SUB("-"){
             public int exec(int a,int b){
                    return a - b;
             }
     };
     String value = "";
     //定义成员值类型
     private Calculator(String _value){
             this.value = _value;
     }
     //获得枚举成员的值
     public String getValue(){
             return this.value;
     }
     //声明一个抽象函数
     public abstract int exec(int a,int b);
}

先想一想它的名字,为什么叫做策略枚举?枚举没有问题,它就是一个Enum类型,那为什么又叫做策略呢?找找看能不能找到策略的影子在里面?是的,我们定义了一个抽象的方法exec,然后在每个枚举成员中进行了实现,如果不实现会怎么样呢?你试试看看,不实现该方法就不能编译,现在是不是清楚了?把原有定义在抽象策略中的方法移植到枚举中,每个枚举成员就成为一个具体策略。简单吧,总结一下,策略枚举定义如下:

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

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

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

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的,扩展性受到了一定的约束,因此在系统开发中,策略枚举一般担当不经常发生变化的角色。

参考文档