已知的“陷阱”有哪些？ 关于责任链模式？
我发现自己经常使用责任链模式（3次是对我来说经常如此）在我当前的项目中，我想知道我是否对这个解决方案变得有点过于热情了。 具体来说，我一直在使用 Apache Commons 链项目。 到目前为止，我对它如何将应用程序逻辑的许多复杂的可互换部分简化为一个更有凝聚力和组织性的整体印象非常深刻。 然而，该项目的一些新人似乎很难“理解”。 您对此有什么经验？ 您在实施过程中遇到了哪些问题？
到目前为止，我注意到的唯一问题是当您尝试处理需要关闭的对象时。 当您完成链的执行时，将这些对象存储在 Context 类中会很痛苦。 我能够使用过滤器而不是命令来解决这个问题，但这似乎有点不直观，因为您的关闭语句通常距离实例化对象的位置很远。
不管怎样，我很想听听一些比我对这种模式有更多经验的开发人员的想法。
提前致谢。
I have been finding myself using the Chain of Responsibility pattern often (3 times is often for me) in my current project and I'm wondering if I have become a little over-enthusiastic about the solution. Specifically, I have been using the Apache Commons chain project. So, far I have been quite impressed by how it has simplified a number of complex interchangeable pieces of app logic into a more cohesive and organized whole. However, a few of the newer people on the project seem to have difficulty "getting it." What are your experiences with it? What problems have you encountered in its implementation?
So far, the only problem I have noticed that it is when you are trying to deal with objects that need to be closed. Having those objects stored in your Context class makes for a pain when you have completed the execution of your chain. I was able to work around this using Filters instead of Commands, but it seems a little unintuitive because your close statements are often very far away from where the object was instantiated.
Anyways, I would love to hear the thoughts from some developers who have more experience that I with this pattern.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说它对于非特定问题（例如框架代码）效果很好，但对于特定问题效果较差。 框架是为其他人使用而编写的，您希望给予客户完全的实施自由。 一旦您确切地知道要做什么来解决问题，我认为其他解决方案会更好。
责任链模式的危险与黑板模式非常相似：很容易最终创建大量抽象，而这些抽象在实现最终目标时大多无法提供价值。 命令对象和处理对象实际上只是将应用程序的逻辑隐藏在处理链后面，而不是将其放在最重要的代码所在的前面。 如果您只编写一个代表完整处理链的方法（或多个方法），而不需要处理链的抽象，那么理解和维护这一点会容易得多。 处理链确实可以隐藏应用程序的业务逻辑，我认为您优先考虑技术工件而不是业务代码。
因此，基本上，您可以用更抽象的处理链来替换可能非常容易读取的非常直接的应用程序代码。 您正在进行元编程。 就我个人而言，我不再进行任何元编程，因此我倾向于同意那些不喜欢它的同事的观点。 ;)
I'm tempted to say it works well for an unspecific problem (e.g. framework code) but works less well for specific problems. Frameworks are written for other people to use, and you want to give the client total freedom of implementation. Once you know exactly what you are going to do to solve the problem, I think other solutions are better.
The danger of the Chain of Responsibility pattern is much the same as for the Blackboard pattern: it's really easy to end up creating a lot of abstractions that mostly don't provide value in delivering your end goal. The command objects and processing objects really just hide the logic of your application behind a processing chain instead of putting it right up front where your most important code is. It is much easier to understand and maintain this if you just program a method (or several methods) that represents the full processing chain without the abstractions of the processing chain. The processing chain can really hide the business logic of your application, and I think you prioritize the technical artifact over the business code.
So basically you replace what could have been very straight-forward application code that reads very easily with much more abstract processing chains. You are doing meta-programming. Personally I never do any meta-programming any more, so I'd tend to agree with those colleagues that dislike it. ;)
我认为可以公平地说，一般来说，如果给定的设计模式给您带来的好处多于成本，那么它是值得使用的。 每个模式都会在代码中引入额外的间接级别，因此更难以遵循，特别是对于团队的初级成员而言。 话虽如此，我认为如果您事先不知道将要进行处理的类是什么（因此位于链中），那么责任链模式绝对有用，或者你在不同的上下文中重用这些类，在不同的场景中创建不同的链，等等。
总的来说，我认为过度设计你的解决方案是非常糟糕的（因为正如你所说，新人们很难理解它），但也有一些情况其中设计模式非常有用。
I think it is fair to say that in general it is worth using a given design pattern if it gives you more benefits then costs. Every pattern introduces extra level of indirection in the code, so it is more difficult to follow, especially for junior members of the team. Having said that I think that the Chain of Responsibility pattern is definitely useful if you don't know upfront what are the classes going to be that are going to do the processing (so being in the chain), or you reuse these classes in different contexts, create different chains in different scenarios, etc.
In general I think it is pretty bad to over-engineer your solutions (because as you said new people struggle with understanding it), but there are some cases where the design patterns are very useful.