Chain of Responsibility | Cheat Sheet
Behavioral Pattern — Design Patterns Series
Chain of Responsibility avoids the coupling between sender and receiver of a request. For this, multiple objects can take part in the process. The whole thing can be thought of as a one-time iteration of a given sequence, which can be variable. Objects are chained together and the request is forwarded until it is accepted and processed. Sometimes there is no processing guarantee.
The queue of a technical support system, where you reach different stages (automated attendant, support staff, administrator) is a good real-time example.
Real-life examples
- Technical support: starting with a recorded message, you are then forwarded to a support employee. If the error could not be solved by then, you will be forwarded to an administrator
- Permit A38 in Asterix and Obelix
- Login on web pages: authentication and authorization
Meaning
- Avoiding the coupling of a request sender with its receiver by allowing multiple objects to process the request
- Received objects are chained together and the request is forwarded until it is accepted and processed
Applicability (suitable if …)
- Requests can be processed by several objects and the handler (processor) is not known from the start and is determined automatically at runtime
- A request is supposed to be directed to one of several objects without explicit specification of the recipient
- Set of objects, which can process requests, is determined dynamically
Assets and Drawbacks
- Reduced coupling (object of processing does not know sender) and thus independent implementation
- Reference to successor object instead of all object candidates
- Additional flexibility in assignment (order, subclassing)
- No processing guarantee
Conductive Thoughts
Chain of Responsibility can also be applied in the microservice world, precisely when it is a question of whether a service accepts and processes a request or passes it on to another service.
Example
An example would be analyzing a random number according to its size. For this, different size handlers take part in it.
The responsibility for such a handler is to set the next handler — if there is one, and accept the request:
The different handlers check if the random number is in their support range — if not, the request will be forwarded to the next one:
The client now only has to define in which order the handlers should be called:
Conclusion
Design Patterns are an important resource and base knowledge for every developer — they are very helpful for solving programmatic problems, help with consistent communication with other developers about system design, and serve as a significant introduction into object composition (besides inheritance) and dependency inversion.
Behavioral Patterns deal with algorithms and assignment of responsibilities to objects. Furthermore, they describe mutual communication patterns and grasp complex program sequences. They are therefore very well suited for use in areas where complicated code needs to be made readable and maintainable. Extensions are in consequence very good and quickly implementable.
