责任链模式

从击鼓传花谈起

击鼓传花是一种热闹而又紧张的饮酒游戏。在酒宴上宾客依次坐定位置，由一人击鼓，击鼓的地方与传花的地方是分开的，以示公正。开始击鼓时，花束就开始依次传递，鼓声一落，如果花束在某人手中，则该人就得饮酒。

击鼓传花便是责任链模式的应用。责任链可能是一条直线、一个环链或者一个树结构的一部分。

面临问题：

某些对象请求的接受者可能多种多样，变化无常……如果根据接受者去设置放松者，显然不可行的，怎样才能解耦发送者和接受者？并且发送者的消息还能被接受者能够执行。

解决方案：

给多个对象处理一个请求的机会，从而解耦发送者和接受者应根据普遍性即从最特殊到最普遍的顺序来组织帮助信息，比如用户界面中会有一个对象来处理帮助请求，但是哪一个对象则取决于上下文。使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

该模式是行为型模式，封装了不断变化的接受者，行为就是发送者给接收者发送消息，因为接收者不断变化，所以这是一个变化的行为，所以封装了起来。责任链模式降低了请求的发送端和接收端之间的耦合，使多个对象都有机会处理这个请求。一个链可以是一条线，一个树，也可以是一个环。

 Handler
 定义一个处理请求的接口
 (可选)实现后继链
 ConcreteHandler
处理它所负责的请求
 可访问它的后继者
 如果可处理该请求，就处理之；否则将该请求转发给它的后继者
 Client
 提交请求

纯的与不纯的责任链模式
 一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一个是承担责任，二是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把责任向下传的情况。
 在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。纯的责任链模式的例子不多见，一般的例子均是不纯的责任链模式的实现。

假如客户买了某公司的一个产品，可是发现产品出了问题，于是打电话到部门A询问，部门A告诉他去问一下部门B，部门B再让他问一下部门C...... 以此类推，最后部门Z终于给他解决了问题。

先设置责任链，部门a，之后部门b，之后部门c等。然后设置请求，然后将请求传给部门，让其执行。

应用：

有多个对象可以处理一个请求，哪个对象处理该请求则在运行时刻确定
在不明确指定接收者的情况下，向多个对象中的一个提交一个请求
可处理一个请求的对象集合应被动态制定

相关的模式：
经常与Composite一起使用。这时，一个构件的父构件可作为它的后继。