职责链.md

职责链 Chain of Responsibility

背景

对于某些依赖上下文的响应机制，例如图形界面中不同部分需要对应不同的帮助信息，而接口都为统一的“帮助”。这一机制的实现需要依据上下文，按普遍性从最特殊到最普遍的顺序来组织帮助信息/响应帮助请求。简单的可以概括为**“基于消息，事件驱动”**。

定义

使多个对象都有机会处理请求，从而**^[1]避免请求的发送者和接收者之间的耦合关系**。将这些对象连成一条链，并**^[2]沿此链传递请求直至被响应**。

难点 & 关键

1. 将请求者和响应者解耦

• 请求者并不明确知道哪一个对象将会响应它 —— 请求有一个**“隐式”的接收者**。

• 响应者有自己明确的职责，能处理就处理，不能处理就让别人处理/将请求传递

2. 链

• 一系列接口一致的“结点” => 能统一地处理请求
• 相邻链接的链要保证至少一方认识另一方 => 为了传递请求

要素

• Handler —— ^[1]统一的响应请求的接口；^[2]一般会在这定义新的链接(可选)

• 表示请求的方式：

  1. 硬编码 —— 请求接口固定
  2. 处理函数 —— 以一个请求码为参数。请求码需要对外公开

• ConcreteHandler ——

  1. 处理它职责范围内地请求
  2. 访问它的后继者(实现上是同层次的)
  3. 判断是否移交请求(可以持有一个状态来表征是否响应)

• client —— 需要创建链(的前后关系)

优点

• 降低耦合度。请求者和响应者都不需要知道对方；链中对象不用知道链的结构。(请求者只要知道会被响应，响应者只要明确自己的职责，链中对象只要知道后继者。)
• 增强了给对象指派职责的灵活性。这里的对象指的是对请求的响应链，通过添加/移除结点增减响应能力。
• 不一定从链头，可以从链中任意结点开始传递请求。

不足

• 不保证一定会被响应。直到链尾都没被响应就不会被响应。
• 如果链中某节点的职责很小，那就可能成为“垃圾对象”。

适用环境

• 希望对某一请求能根据上下文有不同的响应；
• 对请求的响应可以动态指定
• “对事不对人” —— 请求不关心响应者/向多个对象提交请求