如何让孩子爱上设计模式 ——22.责任链模式(Chain of Responsibility Pattern)

标签： 设计模式初涉

描述性文字

定义

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

两个角色

• Handler：抽象处理者，定义抽象请求处理方法，还定义一个抽象处理者对象作为
  其下家的引用，通过该引用，处理者可以连成一条链。
• ConcreteHandler：具体处理者，处理他所负责的请求，如果可处理就处理，不能
  处理就把请求转发给下家。

UML类图

使用场景

• 1.多个对象处理同一个请求，哪个对象处理改请求运行时刻自动确定；
• 2.在不明确指定接收者的情况下，想多个对象中的一个，提交一个请求；
• 3.处理一个请求的对象集合应被动态指定；

优缺点

优点

• 1.请求者与接收者松散耦合
• 2.可以动态组合，请求处理对象只需维持只想其后继者的引用
• 3.扩展灵活，新增具体请求者时无需修改原有系统的代码

缺点

• 1.产生许多细颗粒对象
• 2.不一定能被处理，可能到末端也没被处理或者中间写错
• 3.比较长的责任链，可能涉及多个处理对象，性能问题，还有调试不方便
• 4.建链不当，可能造成循环调用，导致系统进入死循环；

示例代码

写个这种模式烂大街的例子：你问：哥哥，粑粑，麻麻拿零花钱，门槛依次是100,500和1000
然后你按照层级问他们要钱，100以下，哥哥可以给你，100以上的话你要找粑粑，500以上要找
麻麻这样，代码实现下~

先写一个抽象处理者，定义一个抽象的请求方法，下一个抽象处理者的引用

接着依次实现三个具体处理者，哥哥，粑粑和麻麻

最后客户端实例化三个具体处理者，然后依次指定下家，从哥哥开始发送请求

输出结果

好的，关于责任链模式的例子非常简单，另外责任链模式还分纯与不纯

• 纯责任链，要么承担全部责任，要么责任推个下家，不允许在某处承担了部分
  或者全部责任，然后又把责任推给下家。

• 不纯责任链，责任在某处部分或全部被处理后，还向下传递。

本节代码示例

https://github.com/coder-pig/DesignPatternsExample/tree/master/21.Chain%20of%20Responsibility%20Pattern