design-patterns - 关于责任链模式，已知的 "gotchas"是什么？

Question

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

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

无论如何，我很想听听一些对这种模式有更多经验的开发人员的想法。

提前致谢。

Answer 1

我很想说它适用于非特定问题(例如框架代码)，但不适用于特定问题。框架是为其他人编写的，您希望给客户完全的实现自由。一旦您确切地知道要做什么来解决问题，我认为其他解决方案会更好。

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

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