何为策略模式？
策略模式，作为一种常用的设计模式，其通过策略类、方法函数的方式封装不同场景的函数。从而对上层调用，可以屏蔽掉因为入参、场景的差异而导致的区别。而对于内层逻辑，可以根据不同的场景执行不同的方法及类，同时易于增加新的策略，易于拓展。
策略模式主要的组成框架图如下所示：
何时应用策略模式？
这里引用阿里大佬之叶对于什么时候应用策略模式的一段话：
当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的函数式接口可以更有效的简化代码。
