策略模式：精妙替代你的if-else

何为策略模式？

策略模式，作为一种常用的设计模式，其通过策略类、方法函数的方式封装不同场景的函数。从而对上层调用，可以屏蔽掉因为入参、场景的差异而导致的区别。对于内层逻辑，可以根据不同的场景执行不同的方法及类，同时易于增加新的策略，易于拓展。策略模式主要的组成框架图如下所示：

何时应用策略模式？

这里引用阿里大佬之叶对于什么时候应用策略模式的一段话：

当if-else的代码块违反了单一职责原则、开闭原则，尤其是块中的代码量较大时，后续代码的扩展和维护就会变得非常困难且容易出错，使用卫语句也同样避免不了以上两个问题。因此根据我的经验，得出一个我个人认为比较好的实践：

• if-else 不超过 2 层，块中代码 1~5 行，直接写到块中，否则封装为方法
• if-else 超过 2 层，但块中的代码不超过 3 行，尽量使用卫语句
• if-else 超过 2 层，且块中代码超过 3 行，尽量使用策略模式

PS：卫语句如下所示

public Boolean guard(int tags){
  if (tags == 1){
    //内部逻辑代码
    return true;
  }
  if (tags == 2){
    //内部逻辑代码
    return false;
  }
  if(tags == 3){
    //内部逻辑代码
    return true;
  }
}

由此我们也可以引申出另一个方面，策略模式并不多么高大上，它其实只是一个简简单单的if-else就能替代的产物。

怎么使用策略模式

这里假设一个简单的业务背景，假如当前我们是一个算价服务的主要负责人，主要对某商城内不同场景的价格计算服务。

但问题是，商城内价格计算的场景很多，例如：秒杀算价、活动算价、跨店满减算价等等。

如何维护多种算价的情况，以及后续如何更好的接入新算价的场景，成为了你面临的难题。

针对这种情况，你首先想到了采用某种策略来判断当前属于哪个场景，并用if-else来调用对应的算价方法。

public Result calcPrice(CalcPriceParam calcPriceParam){
  //判断对应的计算价格的场景
  Integer type = judgeType(calcPriceParam);
  //根据场景调用不同的方法 ,建议更好的编码习惯是把type改成枚举类型哈～
  if(type == 1){
    return calcPriceForTypeOne();
  }
  if(type == 2){
    return calcPriceForTypeTwo();
  }
  if(type == 3){
    return calcPriceForTypeThree();
  }
  .....
  if(typr == 10){
    return calcPriceForTypeTen();
  }
}

但是这样编写的代码，十分不优雅。于是，你采用了策略模式对代码进行了修改，使得代码变成了下面的样子：

//定义接口，供子类继承
public Interface CalcPriceInterface{
  public Result calcPrice(CalcPriceParam calcPriceParam);
}

@Service
public class StrategyContext{
  Map<Integer,CalcPriceInterface> strategyContextMap = new HashMap<>();
  //注入对应的策略类
  @Autowired
  FirstStrategy firstStrategy;
  @Autowired
  SecondStrategy secondStrategy;
  ......
  @Autowired
  TenStrategy tenStrategy;
    
  @PostConstruct
  public void setStrategyContextMap(){
    //设置对应的方法
    strategyContextMap.set(1,firstStrategy);
    strategyContextMap.set(2,secondStrategy);
    .....
  }

  //根据场景调用不同的方法 
  public Result calcPrice(CalcPriceParam calcPriceParam){
  	Integer type = judgeType(calcPriceParam);
    CalcPriceInterface calcPriceInstance = strategyContextMap.get(type);
    return calcPriceInstance.calcPrice(calcPriceParam);
  }
}

@Autowired
StrategyContext strategyContext;

public Result calcPrice(CalcPriceParam calcPriceParam){
		strategyContext.calcPrice(calcPriceParam);
}

经过这一番重构，随之而来了一个新问题是，每增加一种策略，都需要增加一个策略类，这显然也会增加过多的代码量。

于是，你考虑到了JDK1.8的神器，函数式接口。

Function<CalcPriceParam, CalcPriceDTO> func;

于是代码摇身一变，成了下面的样子：

@Service
public class StrategyContext {
    //当前对应的策略采用lambda的方法存储
    Map<Integer, Function<CalcPriceParam, CalcPriceDTO>> strategyContextMap = new HashMap<>();

    @Resource
    CalcPriceService calcPriceService;

    @PostConstruct
    @SneakyThrows
    public void setStrategyMap() {
      //设置对应的算价逻辑
        strategyContextMap.put(1,(calcPriceParam)-> calcPriceService.calcFirstPrice(calcPriceParam));
        strategyContextMap.put(2,(calcPriceParam)-> calcPriceService.calcSecondPrice(calcPriceParam));
        strategyContextMap.put(3,(calcPriceParam)-> calcPriceService.calcThirdPrice(calcPriceParam));
    }

    public ResultDTO<Object> calcPrice(CalcPriceParam calcPriceParam){
      //判断场景
      Integer type = judgeType(calcPriceParam);
      //获取对应的方法计算并返回
      Function<CalcPriceParam, CalcPriceDTO> calcPriceFunc = strategyContextMap.get(type);
      CalcPriceDTO calcPriceDTO = calcPriceFunc.apply(calcPriceParam);
      return new ResultDTO<>().success(calcPriceDTO);
    }
}

@Service
//对应的计算价格的方法类
public class CalcPriceService {
    public CalcPriceDTO calcFirstPrice(CalcPriceParam calcPriceParam){
        CalcPriceDTO calcPriceDTO = new CalcPriceDTO();
        calcPriceDTO.setResultStr("场景一计算成功");
        return calcPriceDTO;
    }

    public CalcPriceDTO calcSecondPrice(CalcPriceParam calcPriceParam){
        CalcPriceDTO calcPriceDTO = new CalcPriceDTO();
        calcPriceDTO.setResultStr("场景二计算成功");
        return calcPriceDTO;
    }

    public CalcPriceDTO calcThirdPrice(CalcPriceParam calcPriceParam){
        CalcPriceDTO calcPriceDTO = new CalcPriceDTO();
        calcPriceDTO.setResultStr("场景三计算成功");
        return calcPriceDTO;
    }
}

这样一来，不仅代码的维护性提高了，而且对应的代码行数也没有急剧增加。

总结与回顾

1、策略模式并不是什么高大上的东西，其本质是利用map的哈希结构，优化了if-else等不优雅的代码结构。

2、除了多个函数需要封装在一个抽象类的情况，采用JDK1.8的函数式接口可以更有效的简化代码。

参考文献：

设计模式最佳套路1—— 愉快地使用策略模式

新来同事用策略模式把ifelse优化了，技术总监：能不能想好了再改？

策略模式｜菜鸟教程