第20讲：Chain Of Responsibility 职责链模式

2006.8.18 李建忠

请求的发送者与接受者

某些对象请求的接受者可能多种多样，变化无常……

 

动机（Motivation）

在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求发送者与接受者的紧耦合。

如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。

 

意图（Intent）

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

——《设计模式》GoF

 

例说Chain of Responsibility应用

请求的接收者

请求者

这样做请求的发送者和接收者之间耦合得太多。例如list的结构需要请求的发送者来关心和维护。我们希望能把list的维护让请求的发送者忘掉，交给请求的接收者去管理。

 

改进的代码

Next属性相当于链表的next指针，默认的行为都是往后继者去传递请求

能处理的话自己处理，自己不能处理就交给后继者处理。

请求发送者

这样就让请求的接收者自己来负责判断和处理请求，职责剥离交给了请求的接收者，实现发送者和接收者之间彻底解耦。

客户程序

Sender彻底忘掉了以后有多少个Handler，它只需要知道把请求交给一个对象处理就可以了。

 

结构（Structure）

successor是后继者指针，指向自己，Handler里面本身包含了指向自己的指针，把一个链表结构藏在内部，达到解耦。

Chain of Responsibility模式最重要的是把责任封装，把本身应该是请求对象和接收者对象应该耦合的地方剥离，把责任交给接收者对象。我们也可以使多个接收者处理同一个请求。

 

Chain of Responsibility模式的几个要点

Chain of Responsibility模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请求发送者与接受者的耦合才有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。

应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。

当我们要新增一个DHandler处理请求，就不需再改原来的代码了，遵从了开放封闭原则。这样我们的程序就更赋予变化，更有变化的抵抗力。Handler类本身继承自BaseHandler类型，又包含了一个BaseHandler类型的对象，这点类似Decorator模式。

如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。

这种模式在处理UI的消息时很常用，但实际上Windows消息循环还是硬编码的结构。因为效率上的考虑，Windows消息循环是哪个对象有一个请求，则直接到达处理函数的地址。如果链条上的对象多了，而真正处理的函数在链条后部分，效率会很低下。因此我们在使用这种模式的时候更适合业务流程，即对性能要求不是特别高的情况更加常用。

2010.10.21