责任链[GoF]的缺点

Question

我们需要构建一个处理销售订单的解决方案。处理是按顺序进行的：每一步都要处理具体的任务：检查客户是否有信用，检查所需物品是否有库存等。

我们考虑过使用chain of responsibility pattern。

我找到了this old but very valuable article。它首先将CoR与模板模式进行比较。由于我们不关心耦合，所以它们似乎都有用。

我应该注意哪些缺点（或陷阱等）？

Answer 1

这不太合适：责任链模式是关于委派早期步骤无法处理的任务。

在您的情况下，您希望每个步骤都应用，因此CoR并不真正适用。

您真正想要的是某种业务流程引擎，例如jBPM。流程引擎旨在处理这种情况，并为您提供许多在手动解决方案中难以实现的功能，例如：

• 具有持久存储到数据库的长时间运行进程的能力。尝试调试丢失的订单并不是很有趣，因为你必须重新启动服务器....
• 能够等待消息队列上的外部事件（例如，从远程系统获取确认）。在某些简单的情况下可能不需要这样，但如果您与外部供应商整合，它就变得至关重要。
• 处理异常情况并处理回滚/补偿
• 事件记录和报告

基本上，这是我建议不要重新发明轮子的情况之一......

Answer 2

不能与迈克拉达成一致。

1）COR不合适 - 为什么？除了迈克拉所说的，你的问题定义还谈到了结构，即你有一系列的操作（检查信用，检查库存等等），但你选择了责任链，这是一种行为模式。我觉得有些不对劲。

2）不要发明轮子 - 特别是如果你在谈论销售处理等金融工具。

也就是说，完全不同的是，您可以使用Facade设计模式来呈现封装子系统的统一接口。 示例here与您的问题具有相同的业务案例。

Answer 3

CoR不适合您的场景，因为这种模式的一个前提是在其中一个处理程序处理请求后打破链。

根据您的描述，您正在寻找可用作中间件的东西，或者在GoF术语中寻找装饰器。看看这种模式并将其与CoR进行比较，有时可能会混淆。