责任链模式详解与项目应用

什么是责任链模式？

顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。

在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

责任链模式可以避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

优点：

1. 降低耦合度。它将请求的发送者和接收者解耦。
2. 简化了对象。使得对象不需要知道链的结构。
3. 增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
4. 增加新的请求处理类很方便。

缺点：

1. 不能保证请求一定被接收。
2. 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
3. 可能不容易观察运行时的特征，有碍于除错。

项目应用：

现在的项目是一个互联网金融保险类的项目，为客户提供信贷业务。项目是迭代开发，在与银行对接的过程中，有一个接口是用于处理用户借款成功后成立项目的，我们根据银行的要求实现了这个接口的功能并先上线。

再后来加上了还款成功通知的功能，由于这两个功能接口的报文（xml）的字段很多是通用的，于是银行那边为了省事把还款成功通知的功能服用进了项目成立通知接口中，有一个字段来区分这两个功能。

我们需要在接口的入口处，对报文进行解析并区分是什么功能具体走什么项目成立通知还是还款成功通知的逻辑。

可是当还款成功通知功能上线不久后，又来了个新需求是理赔报案功能，因为报文格式相似，银行又懒省事，把这个接口复用进了项目成立通知里，这样一个接口有三个功能：项目成立通知，还款成功通知，理赔报案通知。

这样一来，在原有的接口中修改代码是很麻烦的。这时我们可以考虑使用责任链模式来处理这种问题。

甭管从银行那边传过来的是这三个功能中的哪个，统一传递到一个处理入口，通过责任链来完成任务的处理，这样以后不管这个接口再新增功能，只要写一个新的处理类继承 Handler ，然后修改原责任链的最后一个处理类的 nextHandler 指向新的处理类即可（具体代码实现可参考其他站点，这里只说下思路）。