设计模式-行为型-责任链模式（CHAIN OF RESPONSIBILITY）

接下来我们继续探寻行为型模式。对于这类模式，笔者的理解是。它更多关注在如何抽象出一个或多个实体来把原本可能很复杂的控制流转移成多个职责分明的实体之间的交流上来。这样写出来的代码更容易被理解，同时也更容易被维护。在结构上，这类设计模式多采用组合的方式来实现，当然也有通过类继承的方式来实现，比如模板方法（TEMPLATE METHOD）。

接下来我们来讨论责任链模式。责任链模式的结构图如下所示

 

gof对于责任链模式是这样定义，“使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。”

从它的定义来看，责任链的最终目的是构建出这样一个责任链。请求作为一个对象，附带了这个请求处理相关的信息，组成责任链的节点会解读这个请求，决定是处理该请求或是把请求发给下一个节点。笔者认为这个责任链的节点可以是连续存储的也可以是随机位置存储的，具体怎么做取决于你的实现。

那么责任链的优点在哪儿了呢？ 第一点，它降低了客户与处理者的耦合度，客户只需要知道第一个处理者与它的请求会被“恰当”的处理掉，怎么处理被谁处理它不用关心。第二点，在开始处理之前，你可以针对你当时的需求配置责任链。这种灵活性是体现在责任链的结构上的，本质上说你拿到的责任链就是一个线性表，所以配置责任链本质上就是配置一个线性表。

同时注意到责任链模式并没有保证客户的请求一定会被处理，设计者在设计这条责任链的时候就必须了解这个特性，并提供给客户一个他的请求会被“恰当”处理的保证。这个“恰当”处理可能是被正确的处理掉（比如处理结果可能是触发了一个事件，写了一段内存，写了一句数据等等）也可能是返回一个错误消息（往标准错误输出错误信息等等）。注意到返回一个错误消息肯定是这个责任链中的最后一个处理节点，正如前面讨论到的那样，责任链本质是一个单链表。