Question

我正在学习设计模式以在代码中实现它，我想我找到了一个我认为可以工作但有一个主要缺陷的模式。

我最终的模式是责任链模式。根据我的理解，有一个请求传递给单个处理程序，它将处理请求或将其传递给链。

我看到的唯一问题是它指定一旦处理程序处理处理停止的请求。我希望能够继续保持链接，并为每个处理程序提供处理请求的机会。

问题陈述

我正在创建一个应用程序，它会向公司发送发票，我想知道谁都看了发票并签了名。我们需要确保每个部门都签了账户，财务等。重要的方面只是因为1部门签署它不应该结束我相信在这种模式中发生的过程

完全有可能这种模式可能不适合我，如果可以的话请你建议我一个模式。这不是一个班级项目，只是我学习使用模式并发现它在日常生活中的使用。

Answer 1

我不知道是回答还是评论，但是：

对我来说，这听起来像是在看管道或池，而不是责任链。在链中，驱动思想是链中的每个链接将处理数据或将其传递到下一个链接。然后，一旦链中的链接确实处理了数据，链就会结束。

在管道中，我们的想法是所有步骤都至少会查看数据，尽管它们实际上可能不会根据数据进行任何处理。通常隐含的理解是管道是“线性的”。

在您的情况下，这意味着一个部门需要在下一个部门签字之前签字。管道还意味着数据的状态可能随着它的移动而改变。

由于在您的示例中，听起来每个部门的批准都是独立的，因此您可以使用池。通常我们认为池是一个线程池，但在它的基础上，池可以被认为是一组独立的进程，它们适用于相同的输入数据，每个进程的结果都被收集并以某种形式的集合返回结果。

当然需要考虑一些因素：一旦任何部门否认请求，系统是否应该短路？是否存在复杂的业务逻辑，如A部门和C部门批准，B否认和部门D在截止日期之前没有投票，理论状态需要处理？

我在睡觉前在手机上输入了这个，所以请原谅答案中的任何不足之处。明天我会回来看看它，如果需要的话可以做一些清理工作。

Answer 2

策略模式更适合您的情况。

您需要确定发票的下一个操作是什么。因此基于其状态的发票可以

现在，这些状态中的每一个都具有逻辑行为和下一个状态。您可以使用不同类型的发票（子类）来反映每种状态的行为。

超类（接口/摘要）可以有类似的方法：

needsAction()     : boolean
ownerDepartment() : Department // department it should go to next

然后每个子类都会为这些方法定义自己的逻辑。

这样可以避免模型过于臃肿，并且可能会更糟糕 - 切换案例。