什么是已知的“陷阱”关于责任感模式？ [英] What are the known "gotchas" with regards to the Chain of Responsibilty pattern?

问题描述

我一直在找到自己使用责任链模式在我目前的项目中，我经常会遇到3次，我想知道我是否对这个解决方案有一点过分的热情。具体来说，我一直在使用Apache Commons 链接项目。所以，我已经非常深刻的印象了如何将一些复杂的可互换的应用程序逻辑简化成一个更加凝聚和有组织的整体。然而，这个项目中的一些较新的人似乎很难得到它。你有什么经验？在实现过程中遇到什么问题？

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?

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

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.

提前感谢

推荐答案

我很想说，它对于非特定的问题（例如框架模式）很有用，但是对于很多具体问题。框架是为其他人使用而编写的，您希望为客户提供完全的实施自由。一旦你确切知道你要解决的问题，我认为其他的解决方案是更好的。

I'm tempted to say it works well for an unspecific problem (eg framework mode), but works less well for a lot of specific problem. 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 those for the blackboard pattern; it's really easy to end up creating a lot of abstractions that mostly have don't provide value in delivering your end goal. The command objects and processing objects really just form the logic of your application, and you are hiding it 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 really well, 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 ;)

这篇关于什么是已知的“陷阱”关于责任感模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！