Chain of Responsibility
The problem with a single decision-maker
An approval workflow for purchase orders starts straightforward: if the amount is under $1,000, the team lead approves it. Add manager approval for amounts up to $10,000, then director approval above that. All three conditions end up inside one method:
1# Bad: one method decides everything; adding a VP tier means editing this block.
2def approve_purchase(request: PurchaseRequest, amount: float) -> str:
3 if amount < 1_000:
4 return f"Team lead approved {request.id}"
5 elif amount < 10_000:
6 return f"Manager approved {request.id}"
7 elif amount < 50_000:
8 return f"Director approved {request.id}"
9 else:
10 return f"Rejected: {request.id} exceeds director limit"
Every new approval tier — a VP level at $200,000, or a special CFO tier for capital expenditure — requires opening this function and inserting another branch. The function owns the logic for every approver and knows the thresholds of each. It cannot be extended without being modified.
The same shape appears in middleware pipelines: an HTTP request arrives, and the code checks authentication, then logs the request, then enforces a rate limit, all in a single function. Each new check broadens the function and pushes existing logic further down.
How the pattern works
The Chain of Responsibility pattern addresses this by giving each handler one job: decide whether to handle a request itself, or pass it to the next handler in line. Each handler knows only its own threshold (or responsibility) and holds a reference to the next handler. The sender passes the request to the first handler and has no knowledge of what happens next.
The chain is assembled by the caller, not by the handlers themselves. TeamLeadHandler
links to ManagerHandler, which links to DirectorHandler. A request for $8,500 enters
at the team lead, is declined (too large), forwarded to the manager, and approved there.
The director never sees it.