我正在学习设计模式以在代码中实现它，我想我找到了一个我认为可行但有一个主要缺陷的模式。
我最终采用的模式是责任链模式。据我了解，有一个请求传递给单个处理程序，该处理程序将处理请求或将其传递到链中。
我看到的唯一问题是它指定一旦其中一个处理程序处理了请求，处理就会停止。我想要一些能够持续进行的东西，并让每个处理程序都有机会处理请求。
问题陈述
我正在创建一个应用程序，它将向公司发送发票，我想知道谁查看了发票并签字。我们需要确保每个部门都签字，如账户、财务等。重要的方面只是导致 1 个部门签署它不应该结束我认为以这种模式发生的过程
这种模式完全有可能不适合我，如果是这样，你能建议我一个适合我的模式。这不是一个课堂项目，它只是我学习使用模式并发现它在日常生活中的用途。
我不知道是否将其作为答案或评论，但是：
对我来说，这听起来像是你在看一个管道或池，而不是一个责任链。在一个链中，驱动思想是链中的每个环节要么处理数据，要么将其传递到下一个环节。然后，一旦链中的一个环节确实处理了数据，链就结束了。
在 Pipeline 中，想法是所有步骤都至少会查看数据，尽管它们实际上可能不会根据数据进行任何处理。通常隐含的理解是管道是“线性的”。
在您的情况下，这意味着一个部门需要在下一个部门签字之前签字。管道还意味着数据的状态可能会随着它的移动而改变。
由于在您的示例中听起来每个部门的批准都是独立的，因此您可以使用 Pool。通常我们将池视为线程池，但在此基础上，池可以被视为一组独立的进程，它们应用于相同的输入数据，每个进程的结果被收集并以某种形式的收集返回结果。
当然有一些考虑要考虑：一旦任何部门拒绝请求，系统是否应该短路？是否存在复杂的业务逻辑，例如 A 部门和 C 部门批准、B 部门拒绝和 D 部门在截止日期前不投票是需要处理的理论状态吗？
我在睡觉前在手机上输入了这个，所以请原谅答案中的任何缺陷。我明天会回来看看它，如果需要的话做一些清理工作。
策略模式更适合您的情况。
您需要决定发票的下一步操作是什么。所以发票根据其状态，可以
有薪酬的
得到正式认可的
待批
审查中
草稿
等等
现在这些状态中的每一个都有一个逻辑行为和一个下一个状态。您可以有不同类型的发票（子类）来反映这些状态中的每一个的行为。
超类（接口/抽象）可以有如下方法：
needsAction() : boolean
ownerDepartment() : Department // department it should go to next
然后每个子类将为这些方法定义自己的逻辑。
这将使您的模型免于因太多令人困惑的 if-else 而变得臃肿，并且可能更糟 - 切换案例。