在我当前的项目中，我发现自己经常使用责任链模式（对我来说经常是 3 次），我想知道我是否对解决方案变得有点过度热情。具体来说，我一直在使用 Apache Commons链项目。所以，到目前为止，我对它如何将许多复杂的、可互换的应用程序逻辑简化为一个更有凝聚力和组织性的整体印象深刻。然而，该项目的一些新人似乎很难“得到它”。你有什么经验？您在实施过程中遇到了哪些问题？
到目前为止，我注意到的唯一问题是当您尝试处理需要关闭的对象时。当您完成链的执行时，将这些对象存储在您的 Context 类中会很痛苦。我能够使用过滤器而不是命令来解决这个问题，但这似乎有点不直观，因为您的关闭语句通常离对象实例化的位置很远。
无论如何，我很想听听一些对这种模式有更多经验的开发人员的想法。
提前致谢。
我很想说它对于非特定问题（例如框架代码）效果很好，但对于特定问题效果较差。框架是为其他人使用而编写的，您希望给客户完全的实施自由。一旦你确切地知道你将要做什么来解决这个问题，我认为其他解决方案会更好。
责任链模式的危险与黑板模式非常相似：很容易最终创建大量抽象，而这些抽象大多不会为实现最终目标提供价值。命令对象和处理对象实际上只是将应用程序的逻辑隐藏在处理链后面，而不是将其放在最重要的代码所在的前面。如果您只编写一个表示完整处理链的方法（或几个方法），而不需要处理链的抽象，那么理解和维护这一点要容易得多。处理链确实可以隐藏你的应用程序的业务逻辑，我认为你将技术工件优先于业务代码。
所以基本上你用更抽象的处理链替换了本来可以非常简单易读的应用程序代码。你正在做元编程。就我个人而言，我不再进行任何元编程，所以我倾向于同意那些不喜欢它的同事。;)
我认为可以公平地说，总的来说，如果给定的设计模式能给你带来更多的好处而不是成本，那么它是值得使用的。每个模式都在代码中引入了额外的间接级别，因此更难遵循，尤其是对于团队的初级成员。话虽如此，我认为如果您不知道哪些类将进行处理（因此在链中），或者您以不同的方式重用这些类，我认为责任链模式绝对有用上下文，在不同的场景中创建不同的链等。
一般来说，我认为过度设计您的解决方案是非常糟糕的（因为正如您所说，新人很难理解它），但在某些情况下设计模式非常有用。