春节期间，我用责任链模式重构了业务代码（二）

责任链业务场景设计 
趁热打铁，本小节对使用的真实业务场景进行举例说明。假设业务场景是这样的，我们 系统处在一个下游服务，因为业务需求，系统中所使用的 基础数据需要从上游中台同步到系统数据库

基础数据包含了很多类型数据，虽然数据在中台会有一定验证，但是 数据只要是人为录入就极可能存在问题，遵从对上游系统不信任原则，需要对数据接收时进行一系列校验

最初是要进行一系列验证原则才能入库的，后来因为工期问题只放了一套非空验证，趁着春节期间时间还算宽裕，把这套验证规则骨架放进去

从我们系统的接入数据规则而言，个人觉得需要支持以下几套规则

1. 必填项校验，如果数据无法满足业务所必须字段要求，数据一旦落入库中就会产生一系列问题
2. 非法字符校验，因为数据如何录入，上游系统的录入规则是什么样的我们都不清楚，这一项规则也是必须的
3. 长度校验，理由同上，如果系统某字段长度限制 50，但是接入来的数据 500长度，这也会造成问题
   为了让读者了解业务嵌入责任链模式的前因，这里列举了三套校验规则，当然真实中可能不止这三套。但是 一旦将责任链模式嵌入数据同步流程，就会 完全符合文初所提的开闭原则，提高代码的扩展性

本案例设计模式中的开闭原则通过 Spring 提供支持，后续添加新的校验规则就可以不必修改原有代码
这里要再强调下，设计模式的应用场景一定要灵活掌握，只有这样才能在合适的业务场景合理运用对象的设计模式

既然设计模式场景说过了，最后说一下需要达成的业务需求。将一个批量数据经过处理器链的处理，返回出符合要求的数据分类

 
定义顶级验证接口和一系列处理器实现类没什么难度，但是应该如何进行链式调用呢？

这一块代码需要有一定 Spring 基础才能理解，一起来看下 VerifyHandlerChain 如何将所有处理器串成一条链

 
VerifyHandlerChain 处理流程如下：

1. 实现自 InitializingBean 接口，在对应实现方法中获取 IOC 容器中类型为 VerifyHandler 的 Bean，也就是 EmptyVerifyHandler、SexyVerifyHandler
2. 将 VerifyHandler 类型的 Bean 添加到处理器链容器中
3. 定义校验方法 verify()，对入参数据展开处理器链的全部调用，如果过程中发现已无需要验证的数据，直接返回
   这里使用 SpringBoot 项目中默认测试类，来测试一下如何调用

@SpringBootTest
class ChainApplicationTests {

    @Autowired
    private VerifyHandlerChain verifyHandlerChain;

    @Test
    void contextLoads() {
        List<Object> verify = verifyHandlerChain.verify(Lists.newArrayList("源码兴趣圈", "@龙台"));
        System.out.println(verify);
    }
}

这样的话，如果客户或者产品提校验相关的需求时，我们只需要实现 VerifyHandler 接口新建个校验规则实现类就 OK 了，这样符合了设计模式的原则：满足开闭原则，提高代码的扩展性

熟悉之前作者写过设计模式的文章应该知道，强调设计模式重语义，而不是具体的实现过程。所以，你看咱们这个校验代码，把责任链两种模式结合了使用

上面的代码只是示例代码，实际业务中的实现要比这复杂很多，比如：

1. 如何定义处理器的先后调用顺序。比如说某一个处理器执行时间很长并且过滤数据很少，所以希望把它放到最后面执行
2. 这是为当前业务的所有数据类型进行过滤，如何自定义单个数据类型过滤。比如你接入学生数据，学号有一定校验规则，这种处理器类肯定只适合单一类型
   还有很多的业务场景，所以设计模式强调的应该是一种思想，而不是固定的代码写法，需要结合业务场景灵活变通

责任链模式的好处
一定要使用责任链模式么？不使用能不能完成业务需求？

回答是肯定可以，设计模式只是帮助减少代码的复杂性，让其满足开闭原则，提高代码的扩展性。如果不使用同样可以完成需求

如果不使用责任链模式，上面说的真实同步场景面临两个问题

1. 如果把上述说的代码逻辑校验规则写到一起，毫无疑问这个类或者说这个方法函数奇大无比。减少代码复杂性一贯方法是：将大块代码逻辑拆分成函数，将大类拆分成小类，是应对代码复杂性的常用方法。如果此时说：可以把不同的校验规则拆分成不同的函数，不同的类，这样不也可以满足减少代码复杂性的要求么。这样拆分是能解决代码复杂性，但是这样就会面临第二个问题
2. 开闭原则：添加一个新的功能应该是，在已有代码基础上扩展代码，而非修改已有代码。大家设想一下，假设你写了三套校验规则，运行过一段时间，这时候领导让加第四套，是不是要在原有代码上改动
   综上所述，在合适的场景运用适合的设计模式，能够让代码设计复杂性降低，变得更为健壮。朝更远的说也能让自己的编码设计能力有所提高，告别被人吐槽的烂代码...

Mybatis Interceptor底层实现 
上面说了那么多，框架底层源码是怎么设计并且使用责任链模式的？之前在看 Mybatis 3.4.x 源码时了解到 Interceptor 底层实现就是责任链模式，这里和读者分享 Interceptor 具体实现

开门见山，直接把视线聚焦到 Mybatis 源码，版本号 3.4.7-SNAPSHOT

 
熟悉么？是不是和我们上面用到的责任链模式差不太多，有处理器集合 interceptors，有添加处理器方法

Mybatis Interceptor 不仅用到了责任链，还用到了动态代理，服务于 Mybatis 四大 "护教法王"，在创建对象时通过动态代理和责任链相结合组装而成插件模块

1. ParameterHandler
2. ResultSetHandler
3. StatementHandler
4. Executor
   使用过 Mybatis 的读者应该知道，查询 SQL 的分页语句就是使用 Interceptor 实现，比如市场上的 PageHelper、Mybatis-Plus 分页插件再或者我们自实现的分页插件（应该没有项目组使用显示调用多条语句组成分页吧）

拿查询语句举例，如果定义了多个查询相关的拦截器，会先经过拦截器的代码加工，所有的拦截器执行完毕后才会走真正查询数据库操作

 
扯的话就扯远了，能够知道如何用、在哪用就可以了。通过 Interceptor 也能知道一点，想要读框架源码，需要一定的设计模式基础。如果对责任链、动态代理不清楚，那么就不能理解这一块的精髓

结言 
文章通过图文并茂的方式帮助大家理解责任链设计模式，在两种类型示例代码以及举例实际业务场景下，相信小伙伴已经掌握了如何在合适的场景使用责任链设计模式

看完文章后可以结合 Mybatis、SpringMvc 拦截器更深入掌握责任链模式的应用场景以及使用手法。另外可以结合项目中实际业务场景灵活使用，相信真正使用后的你会对责任链模式产生更深入的了解

文章参考：《设计模式之美：职责链模式》

文章转自公众号：龙台的技术笔记