前言
近期在做Cicada的拦截器功能,正好用到了责任链模式。
这个设计模式在日常使用中频率还是挺高的,借此机会来分析分析。
责任链模式
先来看看什么是责任链模式。
引用一段维基百科对其的解释:
责任链模式在面向对象程式设计里是一种软件设计模式,它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象,它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。
光看这段描述可能大家会觉得懵,简单来说就是该设计模式用于对某个对象或者请求进行一系列的处理,这些处理逻辑正好组成一个链条。
下面来简单演示使用与不使用责任链模式有什么区别和优势。
责任链模式的应用
传统实现
假设这样的场景:传入了一段内容,需要对这段文本进行加工;比如过滤敏感词、错别字修改、最后署上版权等操作。
常见的写法如下:
publicclassMain{ publicstaticvoidmain(String[] args) {Stringmsg ="内容内容内容";Stringresult = Process.sensitiveWord() .typo() .copyright(); }}
这样看似没啥问题也能解决需求,但如果我还需要为为内容加上一个统一的标题呢?在现有的方式下就不得不新增处理方法,并且是在这个客户端(Process)的基础上进行新增。
显然这样的扩展性不好。
责任链模式实现
这时候就到了责任链模式发挥作用了。
该需求非常的符合对某一个对象、请求进行一系列处理的特征。
于是我们将代码修改:
这时Process就是一个接口了,用于定义真正的处理函数。
publicinterfaceProcess{/** * 执行处理 *@parammsg */voiddoProcess(String msg);}
同时之前对内容的各种处理只需要实现该接口即可:
publicclassSensitiveWordProcessimplementsProcess{@OverridepublicvoiddoProcess(String msg){ System.out.println(msg +"敏感词处理"); }}publicclassCopyrightProcessimplementsProcess{@OverridepublicvoiddoProcess(String msg){ System.out.println(msg +"版权处理"); }}publicclassCopyrightProcessimplementsProcess{@OverridepublicvoiddoProcess(String msg){ System.out.println(msg +"版权处理"); }}
然后只需要给客户端提供一个执行入口以及添加责任链的入口即可:
publicclassMsgProcessChain{privateList chains =newArrayList<>() ;/** * 添加责任链 *@paramprocess *@return*/publicMsgProcessChainaddChain(Process process){ chains.add(process) ;returnthis; }/** * 执行处理 *@parammsg */publicvoidprocess(String msg){for(Process chain : chains) { chain.doProcess(msg); } }}
这样使用起来就非常简单:
publicclassMain{publicstaticvoidmain(String[] args){ String msg ="内容内容内容=="; MsgProcessChain chain =newMsgProcessChain() .addChain(newSensitiveWordProcess()) .addChain(newTypoProcess()) .addChain(newCopyrightProcess()) ; chain.process(msg) ; }}
当我需要再增加一个处理逻辑时只需要添加一个处理单元即可(addChain(Process process)),并对客户端chain.process(msg)是无感知的,不需要做任何的改动。
可能大家没有直接写过责任链模式的相关代码,但不经意间使用到的却不少。
比如Netty中的pipeline就是一个典型的责任链模式,它可以让一个请求在整个管道中进行流转。

通过官方图就可以非常清楚的看出是一个责任链模式:

用责任链模式设计一个拦截器
对于拦截器来说使用责任链模式再好不过了。
下面来看看在Cicada中的实现:
首先是定义了和上文Process接口类似的CicadaInterceptor抽象类:
publicabstractclassCicadaInterceptor{publicbooleanbefore(CicadaContext context,Param param)throwsException{returntrue; }publicvoidafter(CicadaContext context,Param param)throwsException{}}
同时定义了一个InterceptProcess的客户端:

其中的loadInterceptors()会将所有的拦截器加入到责任链中。
再提供了两个函数分别对应了拦截前和拦截后的入口:

实际应用
现在来看看具体是怎么使用的吧。

在请求的handle中首先进行加载(loadInterceptors(AppConfig appConfig)),也就是初始化责任链。
接下来则是客户端的入口;调用拦截前后的入口方法即可。
由于是拦截器,那么在before函数中是可以对请求进行拦截的。只要返回false就不会继续向后处理。所以这里做了一个返回值的判断。
同时对于使用者来说只需要创建拦截器类继承CicadaInterceptor类即可。
这里做了一个演示,分别有两个拦截器:
记录一个业务handle的执行时间。
在after里打印了请求参数。
同时可在第一个拦截器中返回false让请求被拦截。
先来做前两个试验:


这样当我请求其中一个接口时会将刚才的日志打印出来:

接下来我让打印执行时间的拦截器中拦截请求,同时输入向前端输入一段文本:

请求接口可以看到如下内容:


同时后面的请求参数也没有打印出来,说明请求确实被拦截下来。
同时我也可以调整拦截顺序,只需要在@Interceptor(order = 1)注解中定义这个order属性即可(默认值是 0,越小越先执行)。
之前是打印请求参数的拦截器先执行,这次我手动将它的 order 调整为 2,而打印时间的 order 为 1 。

再次请求接口观察后台日志:

发现打印执行时间的拦截器先执行。
那这个执行执行顺序如何实现自定义配置的呢?
其实也比较简单,有以下几步:
在加载拦截器时将注解里的order保存起来。
设置拦截器到责任链中时通过反射将order的值保存到各个拦截器中。
最终通过排序重新排列这个责任链的顺序。
贴一些核心代码。
扫描拦截器时保存order值:

保存order值到拦截器中:

重新对责任链排序:

欢迎工作一到八年的Java工程师朋友们加入Java高级交流群:854630135
本群提供免费的学习指导 架构资料 以及免费的解答
不懂得问题都可以在本群提出来 之后还会有直播平台和讲师直接交流噢
哦对了,喜欢就别忘了关注一下哦~
320

被折叠的 条评论
为什么被折叠?



