What are the known “gotchas” with regards to the Chain of Responsibilty pattern?

Question

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-enth

Answer 1

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. ;)