春节期间，我用责任链模式重构了业务代码
共 7510字，需浏览 16分钟
·
2021-02-11 09:44
前言
公众号 源码兴趣圈 写的第 62 篇原创文章
文章开篇，抛出一个老生常谈的问题，学习设计模式有什么作用？
设计模式主要是为了应对代码的复杂性，让其满足开闭原则，提高代码的扩展性
另外，学习的设计模式 一定要在业务代码中落实，只有理论没有真正实施，是无法真正掌握并且灵活运用设计模式的
这篇文章主要说 责任链设计模式，认识此模式是在读 Mybatis 源码时， Interceptor 拦截器主要使用的就是责任链，当时读过后就留下了很深的印象（内心 OS：还能这样玩）
文章先从基础概念说起，另外分析一波 Mybatis 源码中是如何运用的，最后按照 "习俗"，设计一个真实业务场景上的应用
责任链设计模式大纲如下：
什么是责任链模式 完成真实的责任链业务场景设计 Mybatis Interceptor 底层实现 责任链模式总结
什么是责任链模式
举个例子，SpringMvc 中可以定义拦截器，并且可以定义多个。当一个用户发起请求时，顺利的话请求会经过所有拦截器，最终到达业务代码逻辑，SpringMvc 拦截器设计就是使用了责任链模式
为什么说顺利的话会经过所有拦截器？因为请求不满足拦截器自定义规则会被打回，但这并不是责任链模式的唯一处理方式，继续往下看
在责任链模式中，多个处理器（参照上述拦截器）依次处理同一个请求。一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条，链条上的每个处理器 各自承担各自的处理职责
责任链模式中多个处理器形成的处理器链在进行处理请求时，有两种处理方式：
-
请求会被 所有的处理器都处理一遍，不存在中途终止的情况，这里参照 MyBatis 拦截器理解 -
二则是处理器链执行请求中，某一处理器执行时，如果不符合自制定规则的话，停止流程，并且剩下未执行处理器就不会被执行，大家参照 SpringMvc 拦截器理解
这里通过代码的形式对两种处理方式作出解答，方便读者更好的理解。首先看下第一种，请求会经过所有处理器执行的情况
IHandler 负责抽象处理器行为，handle() 则是不同处理器具体需要执行的方法，HandleA、HandleB 为具体需要执行的处理器类，HandlerChain 则是将处理器串成一条链执行的处理器链
public class ChainApplication {
public static void main(String[] args) {
HandlerChain handlerChain = new HandlerChain();
handlerChain.addHandler(Lists.newArrayList(new HandlerA(), new HandlerB()));
handlerChain.handle();
/**
* 程序执行结果：
* HandlerA打印：执行 HandlerA
* HandlerB打印：执行 HandlerB
*/
}
}
这种责任链执行方式会将所有的 处理器全部执行一遍，不会被打断。Mybatis 拦截器用的正是此类型，这种类型 重点在对请求过程中的数据或者行为进行改变
而另外一种责任链模式实现，则是会对请求有阻断作用，阻断产生的前置条件是在处理器中自定义的，代码中的实现较简单，读者可以联想 SpringMvc 拦截器的实现流程
根据代码看的出来，在每一个 IHandler 实现类中会返回一个布尔类型的返回值，如果返回布尔值为 false，那么责任链发起类会中断流程，剩余处理器将不会被执行。就像我们定义在 SpringMvc 中的 Token 拦截器，如果 Token 失效就不能继续访问系统，处理器将请求打回
public class ChainApplication {
public static void main(String[] args) {
HandlerChain handlerChain = new HandlerChain();
handlerChain.addHandler(Lists.newArrayList(new HandlerA(), new HandlerB()));
boolean resultFlag = handlerChain.handle();
if (!resultFlag) {
System.out.println("责任链中处理器不满足条件");
}
}
}
读者可以自己在 IDEA 中实现两种不同的责任链模式，对比其中的不同，设想下业务中真实的应用场景，再或者可以跑 SpringBoot 项目，创建多个拦截器来佐证文中的说辞
本章节介绍了责任链设计模式的具体语义，以及不同责任链实现类型代码举例，并以 Mybatis、SpringMvc 拦截器为参照点，介绍各自不同的代码实现以及应用场景
责任链业务场景设计
趁热打铁，本小节对使用的真实业务场景进行举例说明。假设业务场景是这样的，我们 系统处在一个下游服务，因为业务需求，系统中所使用的 基础数据需要从上游中台同步到系统数据库
基础数据包含了很多类型数据，虽然数据在中台会有一定验证，但是 数据只要是人为录入就极可能存在问题，遵从对上游系统不信任原则，需要对数据接收时进行一系列校验
最初是要进行一系列验证原则才能入库的，后来因为工期问题只放了一套非空验证，趁着春节期间时间还算宽裕，把这套验证规则骨架放进去
从我们系统的接入数据规则而言，个人觉得需要支持以下几套规则
-
必填项校验，如果数据无法满足业务所必须字段要求，数据一旦落入库中就会产生一系列问题 -
非法字符校验，因为数据如何录入，上游系统的录入规则是什么样的我们都不清楚，这一项规则也是必须的 -
长度校验，理由同上，如果系统某字段长度限制 50，但是接入来的数据 500长度，这也会造成问题
为了让读者了解业务嵌入责任链模式的前因，这里列举了三套校验规则，当然真实中可能不止这三套。但是 一旦将责任链模式嵌入数据同步流程，就会 完全符合文初所提的开闭原则，提高代码的扩展性
本案例设计模式中的开闭原则通过 Spring 提供支持，后续添加新的校验规则就可以不必修改原有代码
这里要再强调下，设计模式的应用场景一定要灵活掌握，只有这样才能在合适的业务场景合理运用对象的设计模式
既然设计模式场景说过了，最后说一下需要达成的业务需求。将一个批量数据经过处理器链的处理，返回出符合要求的数据分类
定义顶级验证接口和一系列处理器实现类没什么难度，但是应该如何进行链式调用呢？
这一块代码需要有一定 Spring 基础才能理解，一起来看下 VerifyHandlerChain 如何将所有处理器串成一条链
VerifyHandlerChain 处理流程如下：
-
实现自 InitializingBean 接口，在对应实现方法中获取 IOC 容器中类型为 VerifyHandler 的 Bean，也就是 EmptyVerifyHandler、SexyVerifyHandler -
将 VerifyHandler 类型的 Bean 添加到处理器链容器中 -
定义校验方法 verify()，对入参数据展开处理器链的全部调用，如果过程中发现已无需要验证的数据，直接返回
这里使用 SpringBoot 项目中默认测试类，来测试一下如何调用
@SpringBootTest
class ChainApplicationTests {
@Autowired
private VerifyHandlerChain verifyHandlerChain;
@Test
void contextLoads() {
List