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

2006.8.18 李建忠

请求的发送者与接受者

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

image

 

动机(Motivation)

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

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

 

意图(Intent)

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

——《设计模式》GoF

 

例说Chain of Responsibility应用

请求的接收者

image

请求者

image

image

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

 

改进的代码

image

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

image

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

请求发送者

image

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

客户程序

image

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

 

结构(Structure)

image

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

image

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

 

Chain of Responsibility模式的几个要点

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

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

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

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

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

2010.10.21

posted @ 2010-10-21 21:53  山天大畜  阅读(792)  评论(0编辑  收藏  举报