Chain of Responsibility

The moving parts

The pattern needs only two small ideas — a shared handler interface, and a next pointer that links handlers together:

• A Handler interface — every handler exposes the same two methods: setNext(handler) to wire up the link after it, and handle(request) to receive a request.
• Concrete handlers — each one knows one small rule ('I do password resets', 'I approve refunds up to $100'). In handle(), it either deals with the request or forwards it: return this.next.handle(request).
• The sender — holds a reference to the first link only. It calls firstHandler.handle(request) and walks away. It has no idea how long the chain is or who's in it.
• The end of the chain — the last handler has no next. If the request reaches it and still isn't handled, it goes unhandled — so you choose a fallback: a catch-all default handler, a logged warning, or a returned 'nobody could do this' value.

interface Handler {
  setNext(next: Handler): Handler;   // returns next, so calls can be chained
  handle(req: SupportRequest): string | null;
}

class L1Support implements Handler {
  private next: Handler | null = null;
  setNext(next: Handler) { this.next = next; return next; }

  handle(req: SupportRequest): string | null {
    if (req.kind === "password-reset") {
      return "L1 handled it";               // ✅ my job — stop here
    }
    return this.next ? this.next.handle(req) : null;  // → pass it on
  }
}

// Wiring the hotline — the sender only ever sees 'l1':
const l1 = new L1Support();
l1.setNext(new L2Support()).setNext(new Manager()).setNext(new Director());
l1.handle({ kind: "refund", amount: 5000 });   // travels up to the Manager

Two details matter more than they look. First, order matters: put the Director before L1 and every password reset lands on the Director's desk. Chains usually go cheapest-first or most-specific-first. Second, the chain is built at runtime — it's just objects pointing at each other. You can add a handler, remove one, or reorder the whole ladder while the program runs, and the sender's code doesn't change by a single character.

You already use this every day

• HTTP middleware pipelines — Express's app.use(...) and ASP.NET Core's middleware are chains: each middleware handles the request (auth, logging, compression) and calls next(), or short-circuits with a response.
• DOM event bubbling — a click on a button travels up parent elements until some listener handles it (or calls stopPropagation() — literally breaking the chain).
• Logging levels — a log record passes through loggers/filters; each decides to write it, transform it, or hand it up the logger hierarchy.
• GUI event propagation — desktop toolkits route a keypress from the focused widget up through its containers until something consumes it.
• Servlet filters — Java's FilterChain passes each request through a configurable line of filters before the servlet sees it.

The common win in all of these is decoupling: the code that sends a request is completely separated from the code that handles it. The sender knows one interface and one first link — that's low coupling with each handler keeping one focused job, exactly the goal of [[coupling-and-cohesion]]. And because each link wraps a tiny decision, the pattern feels like a cousin of [[decorator]] — same linked shape, but a decorator always passes through and adds behavior, while a chain handler may stop the walk by handling the request.

Reach for a chain when the handler isn't known up front

Chain of Responsibility earns its keep when who handles the request is a runtime question, not a compile-time one:

• More than one possible handler, decided at runtime — different requests need different levels of authority or expertise, and you can't (or don't want to) hard-code the routing in one big if/else.
• The sender must not know the receiver — you want to add a new approval level or a new middleware without touching a single line of sender code.
• Handlers should be added, removed, or reordered freely — plugin filters, configurable pipelines, escalation ladders that change per customer tier. The chain is just linked objects, so re-wiring is cheap and live.
• Processing in a specific order matters — auth before logging before compression: the chain makes the order explicit and swappable in one place (the wiring).