第20讲Chain Of Responsibility 职责链模式

《第20讲Chain Of Responsibility 职责链模式》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、第20讲：ChainOfResponsibility职责链模式2006.8.18李建忠请求的发送者与接受者某些对象请求的接受者可能多种多样，变化无常…… 动机（Motivation）在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。 意图（Intent）使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，

2、并沿着这条链传递请求，直到有一个对象处理它为止。——《设计模式》GoF 例说ChainofResponsibility应用请求的接收者请求者这样做请求的发送者和接收者之间耦合得太多。例如list的结构需要请求的发送者来关心和维护。我们希望能把list的维护让请求的发送者忘掉，交给请求的接收者去管理。 改进的代码Next属性相当于链表的next指针，默认的行为都是往后继者去传递请求能处理的话自己处理，自己不能处理就交给后继者处理。请求发送者这样就让请求的接收者自己来负责判断和处理请求，职责剥离交给了请求的接收者，实现发送者和接收者之间彻

3、底解耦。客户程序Sender彻底忘掉了以后有多少个Handler，它只需要知道把请求交给一个对象处理就可以了。 结构（Structure）successor是后继者指针，指向自己，Handler里面本身包含了指向自己的指针，把一个链表结构藏在内部，达到解耦。ChainofResponsibility模式最重要的是把责任封装，把本身应该是请求对象和接收者对象应该耦合的地方剥离，把责任交给接收者对象。我们也可以使多个接收者处理同一个请求。 ChainofResponsibility模式的几个要点ChainofResponsibility模

4、式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请求发送者与接受者的耦合才有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。应用了ChainofResponsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。当我们要新增一个DHandler处理请求，就不需再改原来的代码了，遵从了开放封闭原则。这样我们的程序就更赋予变化，更有变化的抵抗力。Handler类本身继承自BaseHandler类型，又包含了一个BaseHandler

5、类型的对象，这点类似Decorator模式。如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。这种模式在处理UI的消息时很常用，但实际上Windows消息循环还是硬编码的结构。因为效率上的考虑，Windows消息循环是哪个对象有一个请求，则直接到达处理函数的地址。如果链条上的对象多了，而真正处理的函数在链条后部分，效率会很低下。因此我们在使用这种模式的时候更适合业务流程，即对性能要求不是特别高的情况更加常用。