Java设计模式之策略设计模式

最新推荐文章于 2025-06-22 22:31:38 发布

原创最新推荐文章于 2025-06-22 22:31:38 发布 · 586 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#android #设计模式

Android技术集锦专栏收录该内容

25 篇文章

订阅专栏

哎~ 这里写图片描述
周末一下就过去了，时光荏苒，打了两天LOL，罪恶感倍增
看看这些：

就算这样，哪有怎样？无数次的超神并没有让我当上CTO，迎娶白富美，走上人生巅峰，从此过上幸福的生活。更多的是一种激情过后的失落感和挫败感。经过挣扎之后我决定沉淀了下来，看看设计模式的精华书籍。或许它能给我带来些许的成就感。

本节内容：

策略模式的使用场景
策略模式的定义
总结

前言

在生活中，人们出门出门交通方式有很多种，有走路，有搭公交，有开宝马，更多的是坐着上亿的地铁。都是出门，采用的交通方式不一样，反过来说，采用不同的交通方式出门。这里就涵盖了策略模式的概念。说到这，很多人就会刻意跳过定义的部分了。不过需要注意一个重要的点，就是出门。出门是共同点。也就是宏观目的是一样的，只不过采用的细节不同。

策略模式使用的场景

在代码里，通常策略模式适用于那种只有2级分支，并且分支比较多的情况下。比如一个switch 下面很多个case，那么就可以考虑一下了。然而，特别是在使用if-esle或者switch case的有些年轻人通常就比较反感了：写的真jb慢，还要分支写，烦躁。有时候吧，一层if-else其实没什么，嵌套多个几层那代码写出来，有多恶心都有，也不好阅读。所以，您可以放心，这种情况是不适合我们策略模式的。
第二种情况，就像有的人走路，有的人坐公交，有开宝马。当他们去到高速路收费站的时候，得高速路费了。走路的人给0元，坐公交的人司机给x元，开宝马的给y元。这都是用过caculate（）方法计算出来的结果。那么传统的if-else写法可能是：

//收费站
public class TollStation {

    private static final int PEOPLE = 666; //行人
    private static final int BUS = 777;  //公交车
    private static final int CAR = 888;  //宝马

    public void main(String[] args) {

        //过来了一辆公交车
        int actType = 777;

        TollStation ts = new TollStation();
        //
        double money = 0d;
        if (actType == BUS) {
            money = busCaculate();
        } else if (actType == PEOPLE) {
            money = peopleCaculate();
        } else if (actType == CAR) {
            money = carCaculate();
        }
        //收钱
    }


    //计算行人路费
    public double peopleCaculate() {
        return 0d;
    }

    //计算公交车路费
    public double busCaculate() {
        return 5d;
    }

    //计算宝马路费
    public double carCaculate() {
        return 10d;
    }
}

这里有三种交通工具，各自收费不一样的。有代码经验的同学就说了，没事的经常干。大部分情况下，判断条件没那么多的。也就写了没事。但是假如条件多了呢，策略模式就派上用场了。

我们先来比较下使用策略模式改装的代码后是这样的：

//收费站
public class TollStation1 {

    private TollCaculator mCaculator;

    public void main(String[] args) {
        TollStation1 ts1=new TollStation1();
        //1.过来了一辆公交车
        BusCaculator busCaculator=new BusCaculator();
        ts1.setCaculator(busCaculator);
        //2.收钱
        double money=busCaculator.caculate();



    }

    public void setCaculator(TollCaculator caculator){
        mCaculator=caculator;
    }

}

//用于计算路费的
public interface TollCaculator {
    double caculate();
}

class PeopleCaculator extends TollCaculator{

    @Override
    public double caculate() {
        return 0d;
    }
}
class BusCaculator extends TollCaculator{

    @Override
    public double caculate() {
        return 5d;
    }
}
class BusCaculator extends TollCaculator{

    @Override
    public double caculate() {
        return 10d;
    }
}

可以看到。一个种交通工具对应一种计费方式，如果要增加，只需要创意见一个类实现Tollcaculator接口并重写它自个的计算方法即可。车来是只需要对收费站set设置一个计算策略即可得到结果。那么收费站的代码臃肿问题解决了， if-else烦躁的判断去除了。代码简短而结构明了。除了这些只管的好处外，核心的增加多种交通个工具问题也可以得到结局。
第三种场景是，工程师们需要刻意的使用安全策略来封装同一类型的多种实现方式。也是可以的。将具体实现延续到子类去了。分离了业务和生产。