Chain of Responsibility Pattern

Definition

The Chain of Responsibility Pattern is a behavioral design pattern that passes a request along a chain of handler objects, each of which decides either to process the request or pass it to the next handler in the chain, decoupling the sender of a request from the object(s) that ultimately handle it.

Overview

The Chain of Responsibility Pattern lets multiple objects have a chance to handle a request without the sender needing to know which object will actually process it, or how many handlers might be involved. Each handler in the chain implements a common interface with a method like `handle(request)` and holds a reference to the next handler; when a handler receives a request, it either processes it (and optionally still forwards it), or, if it can't or shouldn't handle it, passes it along to the next handler in the chain. This decouples the request's sender from its eventual receiver, and lets the set of handlers and their order be configured or reconfigured dynamically without changing the sender's code. The pattern is extremely common in the middleware architecture of web frameworks: an HTTP request in Express.js, ASP.NET Core, or Django passes through a chain of middleware functions — logging, authentication, CORS, body parsing, rate limiting — each of which can inspect, modify, short-circuit, or pass along the request/response before it reaches the final route handler. Exception handling in many languages also follows chain-of-responsibility semantics: an exception propagates up a chain of catch blocks or exception handlers until one matches and handles it. GUI event systems similarly bubble events (like a button click) up through a chain of container widgets, each of which can consume the event or let it continue propagating. A key design decision in implementing Chain of Responsibility is whether the chain guarantees exactly one handler processes each request (as in many validation pipelines) or whether multiple handlers may all process it in sequence (as with logging middleware, which typically doesn't stop the chain). Implementations must also decide what happens if no handler in the chain processes the request — silently dropping it, throwing an error, or falling back to a default handler are all common strategies, and choosing incorrectly is a frequent source of subtle bugs in middleware-heavy systems.

Key Concepts

• Passes a request along a chain of handler objects until one handles it
• Each handler decides to process the request, pass it on, or both
• Decouples the request sender from the eventual handler
• Chain order and membership can be configured/reconfigured dynamically
• Foundational to middleware pipelines in web frameworks
• Underlies exception propagation and GUI event bubbling
• Design choice: single-handler vs. multi-handler chains
• Must define fallback behavior for unhandled requests

Use Cases

Frequently Asked Questions

Related in Programming