关于责任链模式，已知的“陷阱”是什么？

Question

我发现自己在当前的项目中经常使用Chain of Responsibility模式(对我来说通常是3次)，我想知道我是否对这个解决方案变得有点过于热情了。具体地说，我一直在使用Apache Commons chain project。到目前为止，它如何将许多复杂的、可互换的应用程序逻辑简化为一个更有凝聚力和更有条理的整体，给我留下了深刻的印象。然而，项目中的一些新人似乎很难“理解”它。你对它有什么经验？您在实施过程中遇到了哪些问题？

到目前为止，我注意到的唯一问题是当您试图处理需要关闭的对象时。当您完成链的执行时，将这些对象存储在您的Context类中会使您感到痛苦。我可以使用过滤器而不是命令来解决这个问题，但这似乎有点不直观，因为您的close语句通常离实例化对象的位置很远。

无论如何，我很乐意听到一些比我更有经验的开发人员对此模式的想法。

提前谢谢。

Answer 1

我很想说，它对不特定的问题(例如框架代码)很有效，但对特定的问题就不太好了。框架是为其他人编写的，而您希望给予客户端完全的实现自由。一旦你确切地知道你要做什么来解决这个问题，我认为其他的解决方案更好。

责任链模式的危险与Blackboard模式非常相似:很容易最终创建许多抽象，而这些抽象在实现最终目标方面大多没有提供价值。命令对象和处理对象实际上只是将应用程序的逻辑隐藏在处理链后面，而不是直接放在最重要的代码所在的位置。如果您只编写一个(或多个)方法来表示完整的处理链，而不是处理链的抽象，则更容易理解和维护这一点。处理链可以真正隐藏应用程序的业务逻辑，我认为您优先考虑技术工件而不是业务代码。

因此，基本上，您可以用更抽象的处理链替换原本可以非常简单地阅读的应用程序代码。您正在进行元编程。就我个人而言，我再也不做元编程了，所以我倾向于同意那些不喜欢它的同事的观点。;)

Answer 2

我认为公平地说，一般来说，如果一个给定的设计模式能给你带来更多的好处而不是成本，那么使用它是值得的。每种模式都在代码中引入了额外的间接性，因此更难遵循，特别是对于团队的初级成员。话虽如此，我认为如果你不知道将要进行处理的类是什么，或者你在不同的上下文中重用这些类，在不同的场景中创建不同的链，那么责任链模式肯定是有用的。

一般来说，我认为过度设计你的解决方案是非常糟糕的(因为正如你所说的，新人很难理解它)，但在某些情况下，设计模式非常有用。