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

不念不忘少年蓝@ 2023-10-14 10:54 61阅读 0赞

### 何为策略模式？ ###

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

### 何时应用策略模式？ ###

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

> 当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的函数式接口可以更有效的简化代码。

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5Y6f5p2l5piv56yR5YKy6I-M5q6_5LiL_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: https://img-blog.csdnimg.cn/18b1f83fa5164f129c88078e7d483be1.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Y6f5p2l5piv56yR5YKy6I-M5q6_5LiL,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center