Chain of Responsibility 职责链模式

1、chain of responsibility 职责链模式chain of responsibility（职责链模式） chain of responsibility（职责链模式）属于行为型模式。行为型模式不仅描述对象或类的模式，还描述它们之间的通信模式，比如对操作的处理应当如何传递等等。 意图：使多个对象都有机会处理哀求，从而避开哀求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该哀求，直到有一个对象处理它为止。 几乎全部设计模式，在了解到它之前，笔者就已经在实战中碰到过了，因此设计模式确实是从实践中得出的真知。但另一方面，假如没有实战的理解，单看设计模式是枯燥的，而

2、且难以理解的，因此大家学习设计模式时，要结合实际问题思量。 举例子 假如看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我预备了三个例子，让你体味什么场景下会用到这种设计模式。 中间件机制 设想我们要为一个后端框架实现中间件（知道 koa 的学生可以理解为 koa 的洋葱模型），在代码中可以插入随意多个中间件，每个中间件都可以对哀求与响应举行处理。 因为每个中间件只响应自己感爱好的哀求，因此惟独运行时才知道这个中间件是否会处理哀求，那么中间件机制应当如何设计，才干保证其功能和灵便性呢？ 通用协助文案 假如一个大型系统中，任何一个模块点击都会弹出协助

3、文案，但并不是每个模块都有协助文案的，假如一个模块没有协助文案，则显示其父级的协助文案，假如再没有，就继续冒泡到囫囵应用，展示应用级别的兜底协助文案。这种系统应当如何设计？ js 大事冒泡机制 其实 js 大事冒泡机制就是个典型的职责链模式，由于任何 dom 元素都可以监听比如 onclick，不仅可以自己响应大事，还可以用法 event.stoppropagation() 阻挡继续冒泡。 意图说明 js 大事冒泡机制对前端来说太常见了，但我们换个角度，站在点击大事的角度理解，就能重新发觉其设计的精妙之处： 点击大事是叠加在每层 dom 上的，因为 dom 对大事的处理和绑定是动态的，扫瞄器本

4、身不知道哪些地方会处理点击大事，但又要让每层 dom 拥有对点击大事的 平等处理权，所以就产生了冒泡机制，与大事阻挡冒泡功能。 通用协助文案和 js 大事冒泡很类似，只是把点击大事换成了弹出协助文案罢了，其场景机理是一样的。 说到这，我们可以再重新理解一下职责链模式的意图： 意图：使多个对象都有机会处理哀求，从而避开哀求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该哀求，直到有一个对象处理它为止。 哀求指的是某个触发机制产生的哀求，是一个通用概念。避开哀求的发送者和接收者之间的耦合关系，指的是假如我们惟独一个对象有处理哀求的机会，那接收者就与发送者之间耦合了，其他接收

5、者必需通过这个接收者才干继续处理，这种模式不够灵便。 后半句描述的是如何设计，可以实现这个灵便的模式，即将对象连成一条链，沿着链条传递该哀求，直到有一个对象处理它为止。还要理解到，任何一个对象都拥有阻断哀求继续传递的能力。 在中间件机制的例子中，后端 web 框架对 http 哀求的处理就是个运用职责链模式的典型案例，由于后端框架要处理的哀求是平行关系，任何哀求都可能要求被响应，但对哀求的处理是通过插件机制拓展的，且对每个哀求的处理都是一个链条，存在处理、加工、再处理的规律关系。 结构图 handler 就是对哀求的处理，可以看到这里是一条环路，只要处理完之后就可以交给下一个 handler

6、举行处理，可以在中途拦截后中断，也可以穿透整条链路。 concretehandler 是详细 handler 的实现，他们都需要继承 handler 以具备相同的 handlerequest 办法，这样每一个处理中间件就都拥有了处理能力，使得这些对象连成的链条可以对哀求举行传递。 代码例子 职责链实现方式十分多，比如 koa 的洋葱模型实现原理就值得再写一篇文章，感爱好的学生可以阅读 co 源码。这里仅介绍最容易场景的实现计划。 职责链的容易实现模式也分为两种，一种是每个对象本身维护到下一个对象的引用，另一种是由 handler 维护后继者。 下面例子用法 typescript 编写。 pub

7、lic class handler private nexthandler: handler public handle() if(nexthandler) nexthandler.handle() 每个 handler 的默认行为就是触发下一个链条的 handle，因此什么都不做的话，这个链条是彻低打通的，因此我们可以在链条的任何一环举行处理。 处理的方式就是重写 handle 函数，我们在重写时，可以维持对 nexthandler.handle() 的调用，以使得链条继续向后传递，也可以不调用，从而终止链条向后传递。 弊端 职责链模式不保证每个中间件都有机会处理哀求，由于中间件挨次的问题，后面中间件可能被前面的中间件阻断，因此当中间件之间存在不相信关系时，职责链模式并不能保证中间件调用的牢靠性。 另外就是不要扩大设计模式的用法范围，对一堆对象的延续调用就没须要用法职责链模式，由于职责链适合处理对象数量不确定、是否处理哀求由每个对象灵便打算的场景，而确定了对象数量以及是否调用的场景，就没须要用法职责链模式了。 总结 职责链模式是插件机制常用的设计模式，在大事机制、哀求处理中