design-patterns - 这会是一个管道、一个责任链还是其他什么？

Question

我正在构建一个多进程架构，它似乎是管道和责任链的奇怪融合。本质上，我有一个由队列链接的处理程序链。每个处理程序将接收一个表示输入数据的对象，将其转发给下一个处理程序，以便它可以开始处理它，然后确定它是否可以对该数据执行任何操作。

我不相信我可以将其称为管道，因为一步并不真正依赖于下一步。这似乎也不是传统的责任链，因为一个处理程序无法阻止其他处理程序处理该数据。这个设计有一个名字可以帮助我记录这个架构吗？还是我只能将其称为“责任管道”？

Answer 1

我仍然认为这是责任链，即使具体不停止链条。

几种模式非常相似，并且它们确实有变化。我认为查看模式是否适合案例的最佳方法是查看其意图。来自 GoF 的书：

责任链 “通过给多个对象处理请求的机会，避免将请求的发送者与其接收者耦合。链接接收对象并沿着链传递请求，直到一个对象处理它。” （第 223 页）

因此，如果您的处理程序和通过链的对象之间没有耦合，我认为对象将始终落到链的末尾并不重要，即使处理。

Answer 2

从你的描述来看，这是另外一回事。责任链和管道都处理本质上的串行处理。至少如果我正确理解您的描述，您所拥有的基本上是一些并行处理数据的“处理器元素”。

通常，您会使用一组观察者来处理这样的情况，但您的描述也并不真正符合观察者模式。特别是，您的每个处理器元素似乎都知道（至少）一个其他处理器元素。使用观察者模式，观察者通常会互相忽略——每个人都向数据源注册自己，当有新的/更改的数据时，数据源会通知所有的观察者。

我的直接反应是，你最好使用观察者模式，而不是为你所做的事情寻找一个名字。模式的要点之一是以相似的方式解决相似的问题。从事物的声音来看，这可能会更加通用和易于管理。例如，如果您决定从链中删除一个观察者，您显然必须修改另一个观察者才能这样做。使用正常的观察者模式，您可以添加或删除观察者而不改变任何其他观察者（并且其他人甚至不知道任何东西都发生了变化）。

编辑：考虑到独立和链接元素的混合，我看到了两种可能的变体。第一个（可能也是最干净的）是在顶层使用观察者模式，其中一些观察者本身就是管道。

另一种可能性是从 VLIW 处理器中窃取技巧，并且在顶层有一个标志，指示特定元素是否依赖于前一个元素的结果。这使得将管道与独立观察者混合起来变得非常容易，并且如果（例如）有时您关心进行并行处理，则可以很容易地并行执行独立进程，同时为那些需要它的人保持串行执行。

Answer 3

这听起来更像是观察者模式，因为每个处理程序都被通知输入发生了变化（通过包含数据的事件）。