Chain of Responsibility
A chain passes a request through ordered handlers until one accepts it or the chain ends. The order and the unhandled result must be explicit.
What you’ll understand
- A chain passes a request through ordered handlers until one accepts it or the chain ends. The order and the unhandled result must be explicit.
- Evaluate handlers in configured order and stop at the first limit that can handle the request.
- Evaluate the tradeoff: Long chains can hide where a decision occurs. Log the chosen handler and decide whether a request stops or continues after handling.
Useful first: Classes and Objects
The idea and when to recognize it
A chain passes a request through ordered handlers until one accepts it or the chain ends. The order and the unhandled result must be explicit.
- Requirement: Support requests have an effort estimate and handlers have increasing capacity limits.
- Change to anticipate: Route a request to the first capable handler, or report unhandled when no capacity is sufficient.
- Design goal: Evaluate handlers in configured order and stop at the first limit that can handle the request.
Start with the concrete problem
Support requests have an effort estimate and handlers have increasing capacity limits.
Route a request to the first capable handler, or report unhandled when no capacity is sufficient.
| Direct implementation | Revised design |
|---|---|
| Always assigning the first handler overloads it and hides requests that require escalation. | Evaluate handlers in configured order and stop at the first limit that can handle the request. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Long chains can hide where a decision occurs. Log the chosen handler and decide whether a request stops or continues after handling. |
Responsibilities and contracts
Evaluate handlers in configured order and stop at the first limit that can handle the request.
- Dispatcher: Starts the ordered search. Public operations: handle(request)
- Handler: Accepts or delegates. Public operations: limit, next
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A middleware chain can pass a request through authentication, validation, and endpoint handling.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Long chains can hide where a decision occurs. Log the chosen handler and decide whether a request stops or continues after handling.
Common mistake: Always assigning the first handler overloads it and hides requests that require escalation.
- Explain the choice: Evaluate handlers in configured order and stop at the first limit that can handle the request.
- Challenge your choice: Long chains can hide where a decision occurs. Log the chosen handler and decide whether a request stops or continues after handling.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…