相信大家都用过计算器，输入一个数，然后输入运算符，然后再输入一个数，就会根据不同的运算符做不同的运算。
最直接的加减法：
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;
}
}
用户使用：
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));
}
}
这是最简单直接的代码，有什么问题吗？假如用户需要这个计算器支持乘法呢？就要改Calculator类，明显违背了开闭原则，系统也不利于维护。
那么怎么设计成可以扩展的代码呢？就需要策略模式了。
策略模式类图
定义：策略模式也叫政策模式，定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
这个定义是非常明确、清晰的，“定义一组算法”，看看加减法和乘法是不是三个算
法？“将每个算法都封装起来”，那么我们定义一个类，封装算法，可以互换，是不是多态的特征呢？我们用代码把这个定义实现下：
//抽象策略
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;
}
}
策略定义好了，然后定义一个Context封装类，其作用是承装三个策略，根据不同的需要替换：
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);
}
}
用户使用：
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));
}
}
需要增加乘法呢？实现Calculator ，增加乘法算法，直接替换就ok了：
public class Mul implements Calculator {
//乘法运算
public int exec(int a, int b) {
return a*b;
}
}
public class Client {
//加符号
public final static String ADD_SYMBOL = "+";
//减符号
public final static String SUB_SYMBOL = "-";
//乘符号
public final static String MUL_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());
}else if(symbol.equals(MUL_SYMBO)){
context = new Context(new Mul());
}
System.out.println("运行结果为："+a+symbol+b+"="+context.exec(a,b,symbol));
}
}
我们总结下这样的写的优点：
- 算法可以自由切换
这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封
装角色对其进行封装，保证对外提供“可自由切换”的策略。 - 避免使用多重条件判断
如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要
使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维
护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略
家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。 - 扩展性良好
这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易
了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。
当然他也不可避免的具有缺点：
- 策略类数量增多
每一个策略都是一个类，复用的可能性很小，类数量增多。 - 所有的策略类都需要对外暴露
上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违
背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么
意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷，
如工厂方法模式、代理模式或享元模式。
那我们什么应该使用策略模式呢：
- 多个类只有在算法或行为上稍有不同的场景。
- 算法需要自由切换的场景。
例如，算法的选择是由使用者决定的，或者算法始终在进化，特别是一些站在技术前沿
的行业，连业务专家都无法给你保证这样的系统规则能够存在多长时间，在这种情况下策略
模式是你最好的助手。 - 需要屏蔽算法规则的场景。
现在的科技发展得很快，人脑的记忆是有限的（就目前来说是有限的），太多的算法你
只要知道一个名字就可以了，传递相关的数字进来，反馈一个运算结果，万事大吉。
Android中有一个需求场景是不是特别像？有数据的时候，要展示数据；无网络的时候，展示重试界面。对的，就是状态策略，根据不同的状态选取不同的策略，但是我们一般不单独使用策略模式，而是使用工厂方法来实现策略类的声明。也就是利用混编，扬长避短，达到最优的设计。
