策略模式

2019/10/15 posted in  算法

策略模式介绍

在软件开发中也常常遇到这样的情况:实现某一个功能可以有多种算法或策略,我们根绝实际情况选择不同的算法或者策略来完成该功能。
针对这种情况,一种常规的方法是将多种算法写在一个类中。但是当多个算法集中在一个类中时,这个类就会变得臃肿,这个类的维护成本会变高,在维护时也更容易引发错误。如果我们需要增加一种新的排序算法,需要修改封装算法类的源代码。这就明显违反了我们所说的OCP原则和单一职责原则。
如果将这些算法或者策略抽象出来,提供一个统一的接口,不同的算法或者策略有不同的实现类,这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换,这种模式的可扩展性、可维护性也就更高,这就是策略模式。

策略模式的定义

策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

策略模式的使用场景

  • 针对同一类型问题的多种处理方式,仅仅是具体行为有差别时。
  • 需要安全地封装多种同一类型的操作时。
  • 出现同一抽象类有多个子类,而又需要使用if-else或者switch-case来选择具体子类时。

策略模式的简单实现

通常如果一个问题有多个解决方案时,最简单的方式就是利用if-else或者switch-case方式,但是耦合性太高、代码臃肿、难以维护。应用策略模式就能很好地解决这类问题,它将各种方案分离开来,让程序客户端根据具体的需求来动态地选择不同的策略方案。

示例中需要计算不同出行工具的成本,下面是我们第一个版本的代码

public class PriceCalculator {
    //公交车类型
    private static final int BUS = 1;
    //地铁类型
    private static final int SUBWAY = 2;
    
    public static void main(String[] args) {
        PriceCalculator calculator = new PriceCalculator();
        System.out.println("坐16公里的公交车票价为:" + calculator.calculatePrice(16, BUS));
        System.out.println("坐16公里的地铁票价为:" + calculator.calculatePrice(16, SUBWAY));
    }
}

/**
 * 北京公交车,十公里之内一元钱,超过十公里之后没加一元钱可以乘5公里
 * @param km 公里
 * @return
 */
 private int busPrice(int km) {
    //超过十公里的总距离
    int extraTotal = km - 10;
    //超过的距离是5公里的距离
    int extraFactor = extraTotal / 5;
    //超过的距离对5公里取余
    int fraction = extraTotal % 5;
    //价格计算
    int price = 1 + extraFactor * 1;
    return fraction > 0 ? ++price : price;
 }
 
 /**
  * 6公里(含)内3元;6~12公里(含)4元;12~22公里(含)5元;22~32公里(含)6元
  * @param km 公里
  * @return
  */
  private int subwayPrice(int km) {
    if(km <= 6) {
        return 3;
    } else if(km > 6 && km <= 12) {
        return 4;
    } else if(km > 12 && km <= 22) {
        return 5;
    } else if(km > 22 && km <= 32) {
        return 6;
    }
    //其他距离我们简化为7元
    return 7;
  }
  
  int calculatePrice(int km, int type) {
    if (type == BUS) {
        return busPrice(km);
    } else if (type == SUBWAY) {
        return subwayPrice(km);
    }
    return 0;
  }
}

PriceCalculator类很明显的问题就是并不是单一职责,承担了公交车、地铁计费职责。当我们增加一种出行方式就需要在PriceCalculator中增加一个方法来计算出租车出行的价格,并且在calculatePrice函数中增加一个判断

public class PriceCalculator {
    //公交车类型
    private static final int BUS = 1;
    //地铁类型
    private static final int SUBWAY = 2;
    //出租车类型
    private static final int TAXI = 3;
    
    /**
     * 简单计算为每公里2元
     * @param km 公里
     * @return
     */
    private int taxiPrice(int km) {
        return km * 2;
    }
    
    int calculatePrice(int km, int type) {
        if (type == BUS) {
            return busPrice(km);
        } else if (type == SUBWAY) {
            return subwayPrice(km);
        } else if (type == TAXI) {
            return taxiPrice(km);
        }
        return 0;
    }
}

增加出行方式时,我们又需要在calculatePrice中添加if-else,此时很有可能就是复制上一个if-else,然后手动进行修改,手动复制代码也是很容易引入错误的做法之一,这样会使代码变得越来越臃肿,难以维护。

用策略模式进行重构

首先我们需要定义一个抽象的价格计算接口

/**
 * 计算接口
 */
public interface CalculateStrategy {
    /**
     * 按距离来计算价格
     * @param km 公里
     * @return 返回价格
     */
     int calculatePrice(int km);
}

对于每一种出行方式我们都有一个独立的计算策略类,这些策略类都实现了CalculateStrategy接口,例如下面是公交车和地铁的计算策略类:

//公交车价格计算策略
public class BusStrategy implements CalculateStrategy {
    /**
     * 北京公交车,十公里之内一元钱,超过十公里之后每加一元钱可以乘5公里
     * @param km 公里
     * @return
     */
     @Override
     public int calculatePrice(int km) {
        //超过十公里的总距离
        int extraTotal = km - 10;
        //超过的距离是5公里的距离
        int extraFactor = extraTotal / 5;
        //超过的距离对5公里取余
        int fraction = extraTotal % 5;
        //价格计算
        int price = 1 + extraFactor * 1;
        return fraction > 0 ? ++price : price;
     }
}

//地铁价格计算策略
public class SubwayStrategy implements CalculateStrategy {
    /**
     * 6公里(含)内3元;6~12公里(含)4元;12~22公里(含)5元;22~32公里(含)6元
     * @param km 公里
     * @return
     */
    private int calculatePrice(int km) {
        if(km <= 6) {
            return 3;
        } else if(km > 6 && km <= 12) {
            return 4;
        } else if(km > 12 && km <= 22) {
            return 5;
        } else if(km > 22 && km <= 32) {
            return 6;
        }
        //其他距离我们简化为7元
        return 7;
    }
}

我们再创建一个TranficCalculator

//公交出行价格计算器
public class TranficCalculator {
    public static void main(String[] args) {
        TranficCalculator calculator = new TranficCalculator();
        //设置计算策略
        calculator.setStrategy(new BusStrategy());
        //计算价格
        System.out.println("公交车乘16公里的价格:" + calculator.calculatePrice(16));
    }
    
    CalculateStrategy mStrategy;
    
    public void setStrategy(CalculateStrategy strategy) {
        this.mStrategy = strategy;
    }
    
    public int calculatePrice(int km) {
        return mStrategy.calculatePrice(km);
    }
}

通过策略模式添加出租车的计算策略,只需要添加一个出租车计算策略类,然后将该策略设置给TranficCalculator,最好直接通过TranficCalculator对象的计算方法。

//出租车计算策略
public class TaxiStrategy implements CalculateStrategy {
    //价格我们简单计算为公里数*2
    @Override
    public int calculatePrice(int km) {
        return km * 2;
    }
}

将策略注册到TranficCalculator中

//公交出行价格计算器
public class TranficCalculator {
    public static void main(String[] args) {
        TranficCalculator calculator = new TranficCalculator();
        //设置计算策略
        calculator.setStrategy(new TaxiStrategy());
        //计算价格
        System.out.println("出租车乘16公里的价格:" + calculator.calculatePrice(16));
    }
    
    CalculateStrategy mStrategy;
    
    public void setStrategy(CalculateStrategy strategy) {
        this.mStrategy = strategy;
    }
    
    public int calculatePrice(int km) {
        return mStrategy.calculatePrice(km);
    }
}

上述示例清晰展示了二者的区别。前者通过if-else来解决问题,虽然实现较为简单,类型层级单一,但暴露的问题非常明显,即代码臃肿,逻辑复杂,难以升级和维护,没有结构可言;后者则是通过建立抽象,将不同的策略构建成一个具体的策略实现,通过不同的策略实现算法替换。在简化逻辑、结构的同时,增强了系统的可读性、稳定性、可扩展性,这对于较为复杂的业务逻辑显得更为直观,扩展也更为方便。

总结

策略模式主要用来分离算法,在相同的行为抽象下有不同的具体实现策略。这个模式很好地演示了开闭原则,也就是定义抽象,注入不同的实现,从而达到很好地可扩展性。

优点

  • 结构清晰明了、使用简单直观
  • 耦合度相对而言较低,扩展方便
  • 操作封装也更为彻底,数据更为安全

缺点

  • 随着策略的增加,子类也会变得繁多