每个处理程序都可以处理责任链模式中的请求吗？

Question

这里我不再重复提及责任链（CoR）模式定义。但是，我想知道的是，如果链中有一系列处理程序，并且所有处理程序都处理了请求，并且如果起始处理程序失败，则最后的处理程序将不处理请求，是否违反该模式？

我将用一个例子来解释。假设一个允许用户搜索书籍的在线应用程序。当用户提交请求时，系统会执行搜索并显示结果。假设，此功能以CoR模式实现。

第一个处理程序获取请求参数（书籍类别，价格，作者等），并添加其他参数（例如用户国家，地区，从请求中挑选的语言）并进行某些验证。
第二个处理程序获取第一个处理程序的输出并查看数据库并创建结果列表。这些结果将转移到第三个处理程序中。第三个处理程序将命令结果，过滤，更改语言。如果前面的处理程序中的任何一个失败，则以下处理程序将无法完成其工作。

CoR的使用是否违背其概念？或任何其他良好的模式？

Answer 1

责任链通常只有一个处理程序来处理请求。

一个很好的类比来自1970年代的Classic Tootsie Roll Commercial - "How Many Licks"，其中一个男孩（请求）试图得到答案的问题＆＃34;到达中心需要多少舔一个Tootsie Pop？＆＃34;

他去了第一只动物，他不知道答案，但是谁将他送到下一只动物，等等。最后，＆＃34;请求＆＃34;处理完毕，男孩得到答案。

男孩只知道链的起点（顺序给出所有其他动物参考）。

在您的问题中，您似乎有一个定义明确的（静态）处理顺序。除非您需要动态地交换步骤，或者重复使用其他项目中的步骤，否则简单的模块化模式没有任何问题：它被称为简单愚蠢 - KISS。

Answer 2

如果过滤器在功能上依赖于另一个过滤器（即期望在执行之前发生某些事情），那么这两个函数应该在同一过滤器的范围内执行。关于COR的主要逻辑是它的模块性，换句话说，您可以随意添加/删除过滤器，而不会影响管道中数据的流量。

Answer 3

CoR的想法是每个链处理程序都不知道链（如果它无法处理它，只有他的继承者委托请求），并且当你将链元素基于彼此时，你违反了CoR的核心概念。我的眼睛 - 我更喜欢使用装饰器使用原始对象使用其他数据来装饰您的原始对象 - 在您的示例中，您将拥有一个请求参数对象，然后是一个结果对象，它使用此请求的结果来装饰请求参数对象然后是第三个通过排序，过滤和/或更改语言来装饰结果的对象。