20 chain of responsibility职责链模式(行为型)

20 chain of responsibility(行为型)

• • 对于一个请求，能自己做就自己做，做不了就推卸给下一个人；下

一个人能自己做就自己做，不能做再推卸给下一个人。

• • 直接决定由哪个对象负责处理时，就需要推卸责任。我们可以将多

个对象组成一个职责链，然后按照它们在职责链上的顺序一个一个

地找出谁来负责处理。

• • 缺点：延迟
  • 优点：将请求的发送方与其接收方解耦。
  • 动机：
    • 通过给多个对象处理请求的机会，避免将请求的发送方与其接收方耦合。
    • 将接收对象链起来，并沿着链传递请求，直到对象处理它。
  • 什么时候用：
    • 一个以上的对象可以处理一个请求，并且这个处理程序是未知的。应该自动确定处理程序。
    • 您希望向几个对象中的一个发出请求，而不需要显式地指定接收方。
    • 可以处理请求的对象集应该动态指定。
  • 结构：
    • 一个典型的对象结构可能是这样的:
    • 参与者：
      • 处理器
        • 定义了一个处理请求的接口。
        • (可选)实现继承链接。
      • ConcreteHandler
        • 处理它负责的请求。
        • 可以访问它的继承者successor。
        • 如果混凝土处理程序可以处理请求，它就会这样做;否则，它将请求转发给其继任者。
      • 客户机
        • 向链上的一个concrete处理器对象发起请求。
    • 协作：
      • 当客户端发出请求,请求propagates(传播)沿着链之前

concrete处理程序对象负责处理它。

• • 结果：（好处）
    • 减少耦合
      • 客户机不知道哪个对象处理请求。
      • 客户端只需要知道一个请求将被处理
      • 接收方和发送方对彼此都没有明确的认识。
      • 链中的处理器不需要知道链的结构。

 

• • 为对象分配职责时增加灵活性。
    • 您可以将它与子类化结合起来静态地专门化处理程序。
    • 您可以通过在运行时添加或以其他方式更改链来添加或更改处理请求的职责。

• • 结果：（坏处）
    • 接收处理不被保证。
      • 因为一个请求没有明确的接收者，所以不能保证它会被处理。
      • 请求可以从链的末端掉下来而不被处理。
      • 当链没有正确配置时，请求也可以不被处理。
  • 例：