[设计模式笔记]三. 行为型模式--15.Chain Of Responsibility(职责链模式)(一)

行为型模式--Chain Of Responsibility(职责链) 对象行为型模式

一. 意图

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

二. 适用性

在以下条件下使用Responsibility 链:

2.1 有多个的对象可以处理一个请求, 哪个对象处理该请求运行时刻自动确定.

2.2 你想在不明确指定接收者的情况下, 向多个对象中的一个提交一个请求.

2.3 可处理一个请求的对象集合应被动态指定.

三. 模式结构

图1 

四. 角色说明

Handler

定义一个处理请求的接口.

实现后继链.

ConcreteHandler

处理它所负责的请求.

可访问它的后继者.

如果可处理该请求, 就处理之;否则将该请求转发给它的后继者.

Client

向链上的具体处理者(ConcreteHandler)对象提交请求.

五. 说明

当客户提交一个请求时, 请求沿链传递直至有一个ConcreteHandler 对象负责处理它.

要沿链转发请求, 并保证接收者为隐式的(implicit), 每个在链上的对象都有一致的处理请求和访问链上后继者的接口.

Responsibility 链有下列优点和缺点(liabilities):

1. 降低耦合度 接收者和发送者都没有对方的明确的信息, 且链中的对象不需知道链的结构. 结果是, 职责链可简化对象的相互连接。它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用.(通常使用抽象父类指针即可).

2. 增强了给对象指派职责(Responsibility)的灵活性 当在对象中分派职责时, 职责链给你更多的灵活性. 你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责. 

3. 不保证被接受 该请求可能一直到链的末端都得不到处理. (因为这些职责是动态加入的, 例如你正确加入了职责A, 但是可能被后面的加入者破坏, 反正是不保证被处理的).

六. 我的理解: 

1. 这里与Windows的消息处理, 钩子等有一点相似.

就是形成一条处理链, 当有请求过来时, 根据请求的类型判断自己是否要处理, 如果处理则处理, 不处理则扔给下家.(大家按照这样的游戏规则, 各自管好各自的, 别的不需要管(解耦)).(我自己只知道我的下家, 我在整条链中的位置我是不知道的(需不需要知道看你的需求).)

2. 从Chain Of Responsibility模式的结构可以看到, 使用的是继承. 也就是说某对象要加入这条责任链, 该对象对应的类必须是Handler的子类(ConcreteHandler类).

3. 责任链谁来管理? 有请求时, 这里的责任链相对比较简单, 就是从自己开始遍历到链尾(看策略, 也可以从链头遍历到链尾).这里的责任链是单向的.

4. 请求如何表示? 用一个标识符表示, 再封装一点, 把标示符定义成一个类(有接口的或没有接口的都可以).

5. 但有请求是, 把这个请求对象(标识符)传递给请求函数HandleRequest(), 责任链上根据请求对象判断是否处理该请求, 不请求则扔给下家处理.

5. 下图有几条责任链? 3条, 有多少开端, 就有多少条.

图2

你也可以使用专门的责任链对象来管理这些处理对象(但需要把处理对象注册到这条责任链上, 就是把它的指针保存下来了, 但要注意保存的顺序). 责任链可以使用一个全局的责任链对象. 这时, 有请求时, 就是可以从链头遍历到链尾, 也可以从自己出发.

6. 不使用继承行吗?.

不使用继承的话, 每一个对象要创建和维护一个处理对象(使用包含)有一个问题, 怎么记录你的下家(successer)?

七. 相关模式: 

职责链常与Composite一起使用. 这种情况下, 一个构件的父构件可作为它的后继.