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

在我目前的项目中,我经常发现自己经常使用责任链模式(对我来说经常是3次),我想知道我是否对解决方案过于热心.具体来说,我一直在使用Apache Commons 链项目.因此,我对它如何将一些复杂的可互换的应用程序逻辑简化为更具凝聚力和组织性的整体印象深刻.然而,项目中的一些新人似乎很难"得到它".你有什么经历？你在实施中遇到了什么问题？

到目前为止,我注意到的唯一问题就是当你试图处理需要关闭的对象时.将这些对象存储在Context类中会在完成链的执行时产生痛苦.我能够使用Filters而不是Commands来解决这个问题,但它似乎有点不直观,因为你的close语句通常离实例化对象的位置很远.

无论如何,我很想听到一些开发人员的想法,他们对我有这种模式的经验.

提前致谢.

我很想说它适用于非特定问题(例如框架代码)但对特定问题的效果较差.框架是为其他人编写的,您希望为客户提供完全的实施自由.一旦你确切地知道你要做什么来解决问题,我认为其他解决方案更好.

责任链模式的危险与Blackboard模式大致相同:很容易最终创建大量抽象,而这些抽象通常无法为实现最终目标提供价值.命令对象和处理对象实际上只是将应用程序的逻辑隐藏在处理链之后,而不是将其放在最重要代码所在的位置.如果您只编写一个代表完整处理链的方法(或多个方法)而没有处理链的抽象,那么理解和维护它会容易得多.处理链可以真正隐藏应用程序的业务逻辑,我认为您可以优先考虑技术工件而不是业务代码.

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