设计模式学习笔记之-职责链模式CHAIN OF RESPONSIBILITY

CHAIN OF RESPONSIBILITY(职责链)—对象行为型模式 

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

1.此设计模式相对而言还是比较简单易懂的。但在实际运用中很可能掉进“为模式而模式”，首先应该明确，设计模式是为了解决问题而出现。每个设计模式都有其

对应的适用情况，有些问题是不是本身MFC的消息回调，Qt的信号和槽，元对象系统等本身就有更好的解决方案？因为设计模式的引入，本身会加重架构的难度，效率可能也会有所影响。嗯，值得思考。

2.职责链对于请求的封装，如果请求需要长期存在，可以考虑通过“字典”，或者说“表驱动”的方式将请求存储并提供获取的接口。

3.职责链常与C o m p o s i t e一起使用。这种情况下，一个构件的父构件可作为它的后继。

2. 适用性
在以下条件下使用Responsibility 链：
• 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
• 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
• 可处理一个请求的对象集合应被动态指定。
3. 结构

4. 参与者
• H a n d l e r（如H e l p H a n d l e r）
— 定义一个处理请求的接口。
— （可选） 实现后继链。
• C o n c r e t e H a n d l e r（如P r i n t B u t t o n和P r i n t D i a l o g）
— 处理它所负责的请求。
— 可访问它的后继者。
— 如果可处理该请求，就处理之；否则将该请求转发给它的后继者。
• C l i e n t

— 向链上的具体处理者( C o n c r e t e H a n d l e r )对象提交请求。

 

表示请求 可以有不同的方法表示请求。最简单的形式，比如在 H a n d l e H e l p的例子中，
请求是一个硬编码的(hard-coded) 操作调用。这种形式方便而且安全，但你只能转发 H a n d l e r
类定义的固定的一组请求。

为标识请求，R e q u e s t可定义一个访问器( a c c e s s o r )函数以返回该类的标识符。或者，如果
实现语言支持的话，接受者可使用运行时的类型信息。
以下为一个分派函数的框架( s k e t c h )，它使用请求对象标识请求。定义于基类 R e q u e s t中的
G e t K i n d操作识别请求的类型: