This article is a couple of thoughts around specific patterns and specifically the chain of responsibility pattern. As the title obviously states. I think some basic knowledge around certain patterns is required.
In a way it's a bit of a philosophical article.
If you look up what is the recipe for making a chain of responsibility, the most common one, include the following ingredients (if you don't mind my cooking references) :
- Decouples receiver and handler
- Passes the request along a chain of objects
The key idea behind this pattern is to give the opportunity to more than one object to handle a specific request.
Personally I believe, that these attributes are incomplete when describing this pattern, and they are a few rogue attributes that mutate this pattern to a certain degree, those are among others:
- define a chain in the Handler
- define the chain in the Concrete Handler
- the order of the chain does not affect the outcome
- it is acceptable in some cases to let a single object to be handled by more than one object
The last one is a hazy line between the chain of responsibility and visitor pattern.
and if you suddenly add state to each operation in the chain then you start throwing mud at the water and make the line between chain of responsibility and memento (or even orchestration) patterns even more indistinguible.
State is the key here. Chain of responsibility does not have a state whereas memento and orchestration do.
Top comments (0)