设计模式之责任链模式

设计模式之责任链模式

前言

之前觉得责任链模式是一种很高大上的模式，因为它不想策略模式那么随处可见，也不想模板模式那么简单明了，我对责任链模式的了解仅限于一些框架中，如Shiro Filter中或者Dubbo Filter中，只是概念上的简单认识。最近项目中有一个需求，刚好有一个常见可以使用责任链模式，所以就实践了一把。

简单说明

责任链模式类似与大家都玩过的游戏“击鼓传花”，请求的发起者就是开始游戏的人，而玩游戏的人呢则组成了一个处理者链，当喊停的时候，花停留在哪一个人手里，对应就是请求被哪一个具体的人处理了。
请求的发起者发出请求，调用一个处理者，其实是一个处理链，而具体请求是被哪一个处理者处理了，请求的发起者是不知道也不关心的；而对于不同的请求，可能处理链也是不一样的，不同的请求会有不同的处理链，在执行请求的过程中，动态的装配处理链。我个人觉得责任链模式的核心就是责任链的装配。责任链的装配的工作可以是有请求的调用者来装配，根据请求的信息，从处理者列表中选择、组装责任链，我此次就是这么做的（因为相对比较简单）；也可以把这个装配的工作交由框架来组装，这样职责更单一。
这样就可以将请求的发起者和请求的具体处理者解耦，根据请求的信息，每一次都进行处理者的组装，可以做到在运行时动态组装责任链 。

类图

责任链

参与角色

1. Client：调用者
   客户端是请求的发起者，它负责调用一个AbstractHandler，具体请求是被责任链中的哪一个Handler处理了，客户端是不清楚的。

2. AbstractHandler:抽象的执行类
   此类负责定义抽象的Handler，对外提供一个公共的Handler方法供客户端调用

3. ConcreteHandler:具体的执行类
   具体的执行类只处理自己感兴趣的部分，需要判断当前请求自己能否处理，如果可以处理，就自己处理，请求结束；如果处理不了，就将请求转发到下一个ConcreteHandler处理，如果没有下一个Handler，那么请求结束。

举例

以此次项目举例，代码就不粘贴了。系统要对一个发票进行规则判断，而规则有很多种，并且不同种类发票的判断规则是由不同规则组合而成的。当系统就收到一个发票的判断请求时，需要根据发票的信息，组装相应的校验规则，如果有一个规则不满足，那么发票就判断为不符合条件的发票。这里不同的检验规则就是具体的校验处理者，每一次发票过来，就可以获取对应的校验规则链，从而进行处理。

遇到的一些问题

1. 日志问题
   由于是链式调用，所以责任链模式一旦出现问题，调试起来相对来说麻烦一点，所以要在责任链调用过程中关键地方进行日志记录，记录执行链的执行记录。方便出现问题定位问题。
2. 顺序问题
   在装载责任链的时候，特别是使用每一个处理者持有下一个处理者引用的时候，一定要注意不要产生循环引用，否则就会形成死循环。