这会是一个管道，一系列责任还是其他什么？

Question

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

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

Answer 1

我仍然认为这是责任链，即使是没有阻止链条的具体细节。

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

  

责任链“避免   将请求的发送者耦合到   它的接收器不止一个   对象有机会处理请求。   链接接收对象并通过   沿链的要求直到   对象处理它。“（第223页）

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

Answer 2

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

通常情况下，您会使用一组观察者来处理这种情况，但您的描述也不适合观察者模式。特别是，每个处理器元素似乎都知道（至少）一个其他处理器元素。使用观察者模式，观察者通常彼此无视 - 每个观察者都使用数据源进行自我注册，当有新的/更改的数据时，所有观察者都会被数据源通知。

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

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

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

Answer 3

这听起来更像Observer pattern，因为每个处理程序都会收到输入的更改（通过包含数据的事件）。

Answer 4

我认为这是 Blackboard

请参阅此answer以查找类似问题