我们需要构建一个解决方案来处理销售订单。处理是按顺序进行的:每个步骤都处理特定的任务:检查客户是否有信用,检查所需物品是否有库存等。
我们想到了使用责任链模式。
我发现了这篇古老但非常有价值的文章。它首先将 CoR 与模板模式进行比较。由于我们不关心耦合,因此它们似乎都有效。
我应该注意哪些缺点(或陷阱等)?
我们需要构建一个解决方案来处理销售订单。处理是按顺序进行的:每个步骤都处理特定的任务:检查客户是否有信用,检查所需物品是否有库存等。
我们想到了使用责任链模式。
我发现了这篇古老但非常有价值的文章。它首先将 CoR 与模板模式进行比较。由于我们不关心耦合,因此它们似乎都有效。
我应该注意哪些缺点(或陷阱等)?
这不是一个很好的选择:责任链模式是关于委派早期步骤无法处理的任务。
在您的情况下,您希望应用每个步骤,因此 CoR 并不真正适用。
您真正想要的是某种业务流程引擎,例如jBPM。流程引擎旨在准确处理这种情况,并为您提供许多在手动解决方案中难以实现的功能,例如:
基本上,这是我建议不要重新发明轮子的情况之一......
不能更同意 mikera。
1) COR 不适合 - 为什么?除了 mikera 所说的之外,您的问题定义还涉及结构,即您有一系列操作(检查信用、检查库存等),但您选择了责任链,这是一种行为模式。我感觉有些不对劲。
2) 不要发明轮子——尤其是当你在谈论诸如销售处理之类的金融工具时。
也就是说,完全不同的是,您可以使用外观设计模式来呈现一个封装子系统的统一接口。此处的示例与您的问题具有相同的业务案例。
CoR 不适合您的方案,因为此模式的一个前提是一旦请求由其中一个处理程序处理,就会中断链。
根据您的描述,您正在寻找可以用作中间件的东西,或者用 GoF 术语来说,就是装饰器。看看这个模式并将其与 CoR 进行比较,有时两者都会混淆。