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