Chain of Responsibility

TL;DR

O Chain of Responsibility passa uma requisição por uma cadeia de tratadores, cada um decidindo se a processa e/ou a repassa ao próximo — desacoplando quem envia de quem trata. É o padrão por trás de todo pipeline de middleware: servlet filters, a filter chain do Spring Security, o middleware do Express/NestJS, pipelines de validação. Na lente cross-linguagem, o “handler com setNext” do GoF encolhe para uma composição de funções — o middleware moderno ((req, next) => ...) é o Chain of Responsibility funcional. As armadilhas que mais mordem: uma requisição que cai no fim da cadeia sem ninguém tratar (silenciosamente), e a ordem implícita dos elos, frágil e difícil de enxergar.

Uma requisição, vários filtros em sequência

Uma requisição HTTP, antes de chegar ao seu controller, precisa atravessar uma sequência de preocupações: autenticar o usuário, verificar permissão, aplicar rate limit, registrar no log, talvez descomprimir o corpo. Cada uma pode deixar passar (e delegar ao próximo) ou barrar (responder 401, 429 e encerrar). Se você amontoa tudo isso no início do controller, ele acumula responsabilidades que não são dele, e reordenar ou remover uma etapa vira cirurgia.

O Chain of Responsibility organiza isso como uma cadeia: cada tratador (elo) recebe a requisição, faz sua parte e decide se passa adiante. Quem envia a requisição não sabe quantos elos existem nem quem vai tratá-la — só entrega ao primeiro. Adicionar uma etapa é inserir um elo; a ordem da cadeia define o fluxo.

A ideia


graph LR
    R[Requisição] --> A[Auth] -->|passa| P[Permissão] -->|passa| L[RateLimit] -->|passa| H[Controller]
    A -.barra 401.-> X((fim))
    L -.barra 429.-> X

    style A fill:#4A90D9,color:#fff
    style P fill:#4A90D9,color:#fff
    style L fill:#4A90D9,color:#fff
    style X fill:#F5A623,color:#000

Cada elo processa e repassa (seta cheia) ou interrompe a cadeia (seta pontilhada). O emissor conhece só a entrada; a decisão de quem trata emerge da cadeia.

O padrão nas quatro linguagens — o middleware é a forma moderna

Java — a filter chain (Spring Security, servlet filters)

O FilterChain do servlet é o exemplo canônico: cada filtro faz sua parte e chama chain.doFilter(...) para seguir — ou não, encerrando ali:

public class AuthFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        if (!autenticado(req)) { negar(res); return; }   // barra: não chama o próximo
        chain.doFilter(req, res);                          // passa adiante
    }
}

Node / TypeScript e Go — middleware como função + `next`

O middleware do Express é o Chain of Responsibility reduzido a funções: cada uma recebe next e decide chamá-la:

app.use((req, res, next) => {
  if (!autenticado(req)) return res.status(401).end();  // barra
  next();                                                // passa
});

Em Go, o idioma é uma função que envolve o próximo handler (func(http.Handler) http.Handler) — a mesma cadeia, composta por funções.

Python — middleware WSGI/ASGI

Frameworks como Django/FastAPI têm cadeias de middleware idênticas em espírito: cada camada processa a requisição e delega à próxima.

A tese: o Chain of Responsibility “OO clássico” (handlers ligados por setNext, cada um numa classe) encolheu para composição de funções — o middleware. Onde o GoF via uma lista encadeada de objetos handler, o mundo moderno vê uma pilha de funções (req, next). É o mesmo padrão do 08 - Decorator aplicado a requisições — com uma diferença de intenção: no Decorator, todas as camadas agem; no Chain, um elo pode interromper e resolver sozinho.