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