设计模式之——策略模式（Strategy Pattern）及在Android中的应用

相信大家都用过计算器，输入一个数，然后输入运算符，然后再输入一个数，就会根据不同的运算符做不同的运算。

最直接的加减法：

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中有一个需求场景是不是特别像？有数据的时候，要展示数据；无网络的时候，展示重试界面。对的，就是状态策略，根据不同的状态选取不同的策略，但是我们一般不单独使用策略模式，而是使用工厂方法来实现策略类的声明。也就是利用混编，扬长避短，达到最优的设计。