我正在构建一个多进程架构，它似乎是管道和责任链的奇怪融合。本质上，我有一个由队列链接的处理程序链。每个处理程序将接收一个表示输入数据的对象，将其转发给下一个处理程序，以便它可以开始处理它，然后确定它是否可以对这些数据执行任何操作。
我不相信我可以将其称为管道，因为一步并不真正依赖于下一步。这似乎也不是传统的责任链，因为一个处理程序无法阻止其他处理程序处理该数据。这个设计有一个名字可以帮助我记录这个架构吗？还是我只能将其称为“责任管道”？
【问题讨论】：
标签： design-patterns architecture pipeline chain-of-responsibility
我仍然认为这是责任链，即使具体不停止链条。
几种模式非常相似，但也有变化。我认为查看模式是否适合案例的最佳方法是查看其意图。来自 GoF 书：
责任链“避免 将请求的发送者耦合到 通过提供一个以上的接收器 反对处理请求的机会。 链接接收对象并通过 沿着链的请求直到 对象处理它。”（pg.223）
因此，如果您的处理程序与通过链的对象之间没有耦合，我认为对象将始终落到链的末端并不重要，即使已处理。
【讨论】：
根据您的描述，这是另一回事。责任链和管道都处理本质上的串行处理。至少如果我正确理解您的描述，您所拥有的基本上是一些并行处理数据的“处理器元素”。
通常情况下，您会使用一组观察者来处理这样的情况，但您的描述也不真正符合观察者模式。特别是，您的每个处理器元素似乎都知道（至少）一个其他处理器元素。使用观察者模式，观察者通常会互相忽略——每个人都向数据源注册自己，当有新的/更改的数据时，数据源会通知所有的观察者。
我的直接反应是，您最好使用观察者模式，而不是为您所做的事情寻找名称。模式的要点之一是以相似的方式解决相似的问题。从事物的声音来看，这可能会更加通用和易于管理。例如，如果您决定从链中删除一个观察者，您显然必须修改另一个观察者才能这样做。使用正常的观察者模式，您可以添加或删除观察者而不改变任何其他观察者（并且其他人甚至根本不知道任何事情发生了变化）。
编辑：考虑到独立和链接元素的混合，我看到了两种可能的变体。第一个（可能也是最干净的）是在顶层使用观察者模式，其中一些观察者本身就是管道。
另一种可能性是从 VLIW 处理器中窃取技巧，并在顶层有一个标志，指示特定元素是否依赖于前一个元素的结果。这使得将管道与独立观察者混合起来变得非常容易，并且如果（例如）有时您关心进行并行处理，则可以很容易地并行执行独立进程，同时为需要它的人保持串行执行。
【讨论】：
这听起来更像Observer pattern，因为每个处理程序都会收到来自输入的更改通知（通过包含数据的事件）。
【讨论】：