定义

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

举例

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

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

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);       // 得到结果
    }
}

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

总结:

优点:

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

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