设计模式——（2）策略模式

定义

定义一种算法，将每个算法都封装起来，并且使它们之间可以互换。是一种行为类模式。

举例

为了通俗易懂，我们拿各国的税率计算来举例子：

假设当前我们的程序只能支持计算中国和美国的税率：

public class Tax_Cal {

    public int CN_Cal(int x) {       // 计算中国税

    }

    public int US_Cal(int x) {       // 计算美国税

    }
}

这样写看起来没什么问题，但实际上我们想想，如果以后公司还要拓展，开始支持法国，日本等等国家，那么我们这个类就得不断但改啊改，是不是特别麻烦且危险？比如万一和前面的某个国家冲突了，就会影响到前面的计算。

所以我们干脆分开来写，把所有的国家税的计算都独立出来，实现的都是同一个接口，都有一个共同的参数x。

public class Strategy {          // 策略模式
    public int Cal(int x);
}

public class CN_Tax implements Strategy {     // 实现中国税计算接口

    @Override
    public int Cal(int x) {

    }
}

public class US_Tax implements Strategy {     // 实现美国税计算接口

    @jOverride
    public int Cal(int x) {

    }
}

public class Tax_Cal {            // 税计算类

    private Strategy = strategy;         // 定义一个策略

    public void setStrategy(Strategy strategy) {     // 接入策略
        this.strategy = strategy;
    }

    public int getTax(int x) {      // 得到结果
        return this.strategy.cal
    }
}

这样一来，所有的税务计算就互不影响啦，因为它们的计算已经被我们独立出来了，要计算哪一个国家的税，只需要接入该国家的算法，调用一下getTax就可以了。我们来写一下：

public class Test {
    public static void main(string[] args) {
        Tax_Cal tax_cal = new Tax_Cal();       // 实例化对象
        tax_cal.setStrategy(new CN_Tax());     // 接入中国税计算
        int res = tax_cal.getTax(100);       // 得到结果
    }
}

这样就实现了中国的税计算。由此可见，这样设计是更有策略性的，以后要有新的国家加入，不需要再修改原代码，只需要再实现一个新的国家接口就可以了。

总结：

优点：

策略间可以自由的切换，因为它们都实现自同一个抽象。
易于拓展，基本上可以在不改变原有代码的基础上进行拓展。
避免使用多重条件语句，否则就得一直if else, switch case，这样非常不利于维护。

策略模式是一种简单常用的设计模式，一般来说不会单独使用，而是和其它模式混合使用。