public void checkResultDispatcherInit() {
checkResultDispatcher.put("校验1", order -> String.format("对%s执行业务逻辑1", order));
checkResultDispatcher.put("校验2", order -> String.format("对%s执行业务逻辑2", order));
checkResultDispatcher.put("校验3", order -> String.format("对%s执行业务逻辑3", order));
checkResultDispatcher.put("校验4", order -> String.format("对%s执行业务逻辑4", order));
checkResultDispatcher.put("校验5", order -> String.format("对%s执行业务逻辑5", order));
checkResultDispatcher.put("校验6", order -> String.format("对%s执行业务逻辑6", order));
checkResultDispatcher.put("校验7", order -> String.format("对%s执行业务逻辑7", order));
checkResultDispatcher.put("校验8", order -> String.format("对%s执行业务逻辑8", order));
checkResultDispatcher.put("校验9", order -> String.format("对%s执行业务逻辑9", order));
}
public String getCheckResultSuper(String order) {
//从逻辑分派Dispatcher中获得业务逻辑代码,result变量是一段lambda表达式
Function<String, String> result = checkResultDispatcher.get(order);
if (result != null) {
//执行这段表达式获得String类型的结果
return result.apply(order);
}
return "不在处理的逻辑中返回业务错误";
}
}
通过http调用一下看看效果:
/**
-
模拟一次http调用
*/
@RestController
public class BizController {@Autowired
private BizService bizService;@PostMapping("/v1/biz/testSuper")
public String test2(String order) {
return bizService.getCheckResultSuper(order);
}
}
![](https://upload-images.jianshu.io/upload_images/13465705-b61cb668adbed0ff.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这是个简单的demo演示,之后会举一些复杂的场景案例。
鲁迅曾说过,“每解决一个问题,就会因出更多的问题”。我们一起来看看这样的实现有什么好处,会带来什么问题。
![](https://upload-images.jianshu.io/upload_images/13465705-9fb11e070b16f343.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
好处很直观:
1. 在一段代码里直观的看到"判断条件"与业务逻辑的映射关系
2. 不需要单独定义接口与实现类,直接使用现有的函数式接口(什么?不知道函数式接口?快去了解),而实现类直接就是业务代码本身。
不好的点:
1. 需要团队成员对lambda表达式有所了解(什么?Java14都出来了还有没用上Java8新特性的小伙伴?)
接下来我举几个在业务中经常遇到的if else场景,并用Map+函数式接口的方式来解决它
## 在真实业务场景问题的解决思路
有的小伙伴会说,我的判断条件有多个啊,而且很复杂,你之前举个例子只有单个判断逻辑,而我有多个判断逻辑该怎么办呢?
很好解决:写一个判断逻辑的方法,Map的key由方法计算出
/**
-
某个业务服务类
*/
@Service
public class BizService {private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();
/**
- 初始化 业务逻辑分派Map 其中value 存放的是 lambda表达式
*/
@PostConstruct
public void checkResultDispatcherMuitInit() {
checkResultDispatcherMuti.put(“key_订单1”, order -> String.format(“对%s执行业务逻辑1”, order));
checkResultDispatcherMuti.put(“key_订单1_订单2”, order -> String.format(“对%s执行业务逻辑2”, order));
checkResultDispatcherMuti.put(“key_订单1_订单2_订单3”, order -> String.format(“对%s执行业务逻辑3”, order));
}
public String getCheckResultMuti(String order, int level) {
//写一段生成key的逻辑:
String ley = getDispatcherKey(order, level);Function<String, String> result = checkResultDispatcherMuti.get(ley); if (result != null) { //执行这段表达式获得String类型的结果 return result.apply(order); } return "不在处理的逻辑中返回业务错误";
}
/**
- 判断条件方法
*/
private String getDispatcherKey(String order, int level) {
StringBuilder key = new StringBuilder(“key”);
for (int i = 1; i <= level; i++) {
key.append("_" + order + i);
}
return key.toString();
}
}
- 初始化 业务逻辑分派Map 其中value 存放的是 lambda表达式
用http模拟一下:
/**
-
模拟一次http调用
*/
@RestController
public class BizController {@Autowired
private BizService bizService;@PostMapping("/v1/biz/testMuti")
public String test1(String order, Integer level) {
return bizService.getCheckResultMuti(order, level);
}
}
![](https://upload-images.jianshu.io/upload_images/13465705-1b180cde89c11c8b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
只要设计好你的key的生成规则就好。
还有小伙伴会问:我的业务逻辑有很多很多行,在checkResultDispatcherMuitInit()方法的Map中直接写不会很长吗?
直接写当然长了,我们可以抽象出一个service服务专门放业务逻辑,然后在定义中调用它就好了:
提供一个业务逻辑单元:
/**
-
提供业务逻辑单元
*/
@Service
public class BizUnitService {public String bizOne(String order) {
return order + “各种花式操作1”;
}
public String bizTwo(String order) {
return order + “各种花式操作2”;
}
public String bizThree(String order) {
return order + “各种花式操作3”;
}
}
/**
-
某个业务服务类
*/
@Service
public class BizService {
@Autowired
private BizUnitService bizUnitService;private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();
/**
- 初始化 业务逻辑分派Map 其中value 存放的是 lambda表达式
*/
@PostConstruct
public void checkResultDispatcherComXInit() {
checkResultDispatcherComX.put(“key_订单1”, order -> bizUnitService.bizOne(order));
checkResultDispatcherComX.put(“key_订单1_订单2”, order -> bizUnitService.bizTwo(order));
checkResultDispatcherComX.put(“key_订单1_订单2_订单3”, order -> bizUnitService.bizThree(order));
}
public String getCheckResultComX(String order, int level) {
//写一段生成key的逻辑:
String ley = getDispatcherComXKey(order, level);Function<String, String> result = checkResultDispatcherComX.get(ley); if (result != null) { //执行这段表达式获得String类型的结果 return result.apply(order); } return "不在处理的逻辑中返回业务错误";
}
/**
- 判断条件方法
*/
- 初始化 业务逻辑分派Map 其中value 存放的是 lambda表达式
言尽于此,完结
无论是一个初级的 coder,高级的程序员,还是顶级的系统架构师,应该都有深刻的领会到设计模式的重要性。
- 第一,设计模式能让专业人之间交流方便,如下:
程序员A:这里我用了XXX设计模式
程序员B:那我大致了解你程序的设计思路了
- 第二,易维护
项目经理:今天客户有这样一个需求…
程序员:明白了,这里我使用了XXX设计模式,所以改起来很快
- 第三,设计模式是编程经验的总结
程序员A:B,你怎么想到要这样去构建你的代码
程序员B:在我学习了XXX设计模式之后,好像自然而然就感觉这样写能避免一些问题
- 第四,学习设计模式并不是必须的
程序员A:B,你这段代码使用的是XXX设计模式对吗?
程序员B:不好意思,我没有学习过设计模式,但是我的经验告诉我是这样写的
从设计思想解读开源框架,一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读,我都已收集整理全套,篇幅有限,这块只是详细的解说了23种设计模式,整理的文件如下图一览无余!
2BYlgEuq-1628627028163)]
从设计思想解读开源框架,一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读,我都已收集整理全套,篇幅有限,这块只是详细的解说了23种设计模式,整理的文件如下图一览无余!
[外链图片转存中…(img-XBm6mZ7D-1628627028165)]
搜集费时费力,能看到此处的都是真爱!