Trade-offs & anti-padrões de AOP

Os treze conceitos anteriores apresentaram cada ferramenta da caixa moderna de aspect-driven: o vocabulário de Kiczales, o decorator e a higher-order function como base, middleware e interceptor como aplicações de pipeline, proxy e weaving como mecânica, e cinco famílias clássicas de cross-cutting concerns — logging, observabilidade, resiliência, cache, autenticação, transação, validação. Este conceito final fecha o módulo olhando o quadro inteiro. Quando aspect é a escolha certa, e quando ele é o caminho mais elegante para um sistema que ninguém entende? Quais anti-padrões aparecem repetidamente, e como evitá-los?

A síntese de uma vida inteira de AOP — desde o paper de Kiczales em 1997 até as bibliotecas de 2026 — pode ser reduzida a uma tensão central. Modularização de cross-cutting concerns é necessária em qualquer sistema não-trivial; sem aspect, cada handler tem cinco linhas de boilerplate antes de chegar à regra de negócio. Ao mesmo tempo, aspect mal organizado é a forma mais elegante de produzir sistema indebugável — onde ler o código local não basta para entender o que executa. Equipes maduras navegam essa tensão com critério: aplicam aspect onde o benefício de modularização supera o custo de indireção, e preferem composição explícita quando a indireção paga mais caro do que economiza.

Este conceito enuncia os anti-padrões mais frequentes de forma sistemática, articula heurísticas para escolher entre aspect e composição explícita, e fecha o módulo com a régua do senior — uma frase única que captura o critério.

O escopo deste fechamento é deliberado. Não se trata de ensinar mais ferramentas; trata-se de articular o julgamento sobre quando usar as que já foram apresentadas. É também o conceito que vai ficar mais útil em entrevista de design e em revisão de código de PRs novos: reconhecer cheiros, propor alternativas, e justificar com vocabulário maduro.

Os trade-offs em quatro eixos

Cada decisão de aspect-driven movimenta quatro variáveis simultaneamente. Aspect bem escolhido melhora algumas e piora outras de forma aceitável; aspect mal escolhido piora todas. Articular os quatro eixos é parte do trabalho de design.

Modularidade vs indireção

Aspect modulariza um cross-cutting concern em um lugar único (ganha modularidade) ao custo de espalhar referências implícitas pelo código que ele afeta (perde indireção). O ponto de ouro é quando o ganho de modularidade compensa o custo. Para concerns universais (logging, correlation ID, auth), o ganho é claro. Para regras locais ("só esse handler faz X"), o custo de aspect supera o benefício — função explícita é mais clara.

Reuso vs explicitude

Aspect favorece reuso (uma definição, muitos pontos de aplicação) em troca de explicitude (cada ponto de aplicação vira menos óbvio sem ler o aspect). Frameworks "convenientes" (Spring AOP com pointcuts amplos, AspectJ com magia full) empurram o eixo para reuso máximo; frameworks "explícitos" (FastAPI Depends, ASP.NET Core middleware registrado em ordem) empurram para explicitude. Equipes que preferem código legível durante onboarding tendem a ganhar com explicitude.

Performance vs flexibilidade

Compile-time weaving (source generators, AspectJ ajc) entrega performance idêntica a código manual. Runtime weaving (proxy dinâmico, decorator instanciado em DI) tem overhead pequeno mas mensurável. A flexibilidade é inversa: runtime permite mudar aspects sem rebuild; compile-time exige rebuild para ajustar. Em sistemas de alta performance, vale source generator; em sistemas que precisam de configuração dinâmica, vale runtime.

Debug-friendly vs debug-resistant

Esse é o eixo mais importante e o mais ignorado. Aspect que atua silenciosamente (Spring AOP via proxy, AspectJ load-time weaving) torna o sistema mais elegante na escrita e mais difícil no diagnóstico. Stack traces passam por classes sintéticas, ponto de execução vira não-óbvio, ordem entre aspects emergente. Em times com bom ferramental (IDE com integração de aspect, observabilidade rica) o custo é menor; em times sem isso, é alto.

Os sete anti-padrões frequentes

1. Magia escondida — aspect que ninguém nota

Sintoma: alguém adiciona @Transactional a um método e a transação não abre porque o método é chamado via this; alguém adiciona aspect de logging com pointcut amplo que registra dado sensível sem ninguém perceber; alguém configura behavior MediatR que fica em branco e ninguém remove. Causa: aspect aplicado em ponto onde o leitor do código local não tem como saber. Defesa: preferir aspect com pointcut explícito (atributo na classe ou no método, registro programático em DI) sobre pointcut declarativo amplo. Em ASP.NET Core, [ServiceFilter(typeof(X))] é mais legível que filter global; em Spring, @Transactional(propagation = REQUIRED) explícito ganha de pointcut "all services" via XML.

2. AOP como martelo

Sintoma: tudo vira aspect — autorização inline foi promovida a filter, validação local virou behavior, lookup de catálogo virou interceptor. O time se entusiasma com o ganho de modularidade e aplica indiscriminadamente. Causa: tendência cognitiva de "se ferramenta nova é boa, mais é melhor". Defesa: a heurística do conceito 01 (universalidade, uniformidade, ortogonalidade ao domínio, estabilidade). Aspect que falha em qualquer uma dessas quatro condições devia ser função explícita.

3. Ordem implícita

Sintoma: cinco middlewares registrados em ordem que parece arbitrária; troca de duas linhas faz testes passarem mas muda o comportamento em produção. Causa: ordem do pipeline decidida por trial-and-error, não por design. Defesa: documentar a ordem do pipeline em arquivo docs/architecture.md (ou no próprio Program.cs com comentários), justificando a posição de cada camada. Em revisão, qualquer mudança de ordem precisa de justificativa explícita.

4. Aspect com lógica de domínio

Sintoma: filter calcula imposto, behavior decide preço, interceptor aplica regra de negócio. A regra de negócio fica escondida em código de plumbing, longe do contexto onde deveria ser raciocinada. Causa: tentação de "aproveitar" a visibilidade do aspect (que vê todos os requests) para aplicar regra cruzada. Defesa: regras de domínio vivem no domínio. Aspect aplica plumbing — log, métrica, retry, auth, cache, transação. Quando aspect começa a ler valor de negócio para decidir, é sinal de migrar para o lugar certo.

5. Pilha de decorators que não cabe na cabeça

Sintoma: RetryDecorator(LoggedDecorator(MetricsDecorator( CachedDecorator(SecuredDecorator(ServiceImpl()))))). A pilha tem sete camadas, cada uma fazendo coisa pequena, e ninguém consegue ler o stack trace. Causa: granularidade excessivamente fina; "cada coisa um decorator". Defesa: agrupar concerns relacionados em um decorator coerente (ResilienceDecorator que faz retry + breaker + timeout conjuntamente) ou subir para abstração mais forte (pipeline declarativo nomeado). Heurística: cinco camadas é teto; se passou, está pedindo refatoração.

6. Cross-cutting que precisa conversar entre si

Sintoma: o decorator de retry quer saber se o decorator de circuit breaker está aberto; o decorator de cache quer saber se o de retry vai fazer nova tentativa. As camadas precisam se comunicar mas decorator é pilha linear. Causa: composição linear não é a abstração certa quando os concerns são estado-dependentes. Defesa: subir para policy nomeada (Polly v8 ResiliencePipeline faz isso — coordena retry, timeout e breaker explicitamente) ou usar framework com modelo correto (orquestração via state machine, não via pilha).

7. Aspect aplicado a interfaces instáveis

Sintoma: toda mudança de interface do serviço base força mudança de seis decorators; cada novo método obriga a reescrever atributos em cada decorator. Causa: aspect via decorator de classe que implementa toda a interface. Quando a interface muda, todos os decorators mudam. Defesa: aspect via interceptor genérico (Castle DynamicProxy) que opera no nível de chamada, não da interface. Ou estabilizar a interface antes de aspectizar.

Quando preferir composição explícita

Composição explícita — função que recebe e retorna função do mesmo tipo, ou objeto que envelopa outro do mesmo tipo, sem DI mágica nem proxy — tem virtudes que o aspect "puro" não tem. A leitura local conta a história inteira. Um caminho conta a leitura inteira. Refatoração é mecânica.

Composição explícita ganha em pelo menos cinco situações. Primeira: equipes com ferramental fraco para AOP (sem IDE com integração, sem profiler que entende proxies, sem observabilidade rica). Segunda: sistemas em linguagens onde a cultura prefere assim (Go, Rust). Terceira: módulos onde a clareza local é prioridade (código crítico, hot path, código que muitos mexem). Quarta: cross-cutting com poucos pontos de aplicação (3-5 — não vale aspect). Quinta: cross-cutting com lógica condicional complexa (a aspect com vários if dentro vira difícil de raciocinar).

Aspect via framework ganha quando: o cross-cutting tem universalidade alta (todo handler do tipo X), uniformidade sólida (a regra é a mesma em todos os pontos), e estabilidade (a regra muda pouco). Logging, correlation ID, auth básica, tracing — todos batem nessas condições. Cache e retry batem em ambientes específicos. Validação fica num híbrido — borda como aspect, domínio como código direto.

O fluxo de decisão

Em situações de design ou revisão, o fluxo de decisão pode ser articulado em quatro perguntas:

1. Esse concern é cross-cutting? Aplicar a heurística do conceito 01 (universal, uniforme, ortogonal, estável). Se não passa, fica como função explícita chamada onde precisa. Concerns locais não merecem aspect.

2. Se é cross-cutting, qual o escopo? Borda HTTP genérica → middleware. Operação específica (precisa do tipo do handler ou do recurso) → interceptor / filter / behavior. Camada de infraestrutura (cliente HTTP, repositório) → decorator. Decisões transversais ao domínio todo → policy engine externo. A escolha é do tipo de aspect, não se vai virar aspect.

3. Que técnica de weaving? Compile-time (source generator) se performance é crítica e acoplamento ao compilador é aceitável. Runtime via proxy se flexibilidade de configuração importa. Composição explícita se a cultura da linguagem prefere e o ganho de magia não compensa.

4. Como vai ser observado e debugado? Aspect sem observabilidade é experiência ruim. Antes de mergir, articule: que log o aspect emite? Que métrica? Que span? Como alguém vai diagnosticar quando ele não atua? Aspect que não responde a essas perguntas vai voltar como bug.

A frase que decide

A heurística do senior, refinada por treze conceitos anteriores, cabe em uma frase: "se eu precisar rodar o sistema para descobrir o que executa antes do meu método, o nível de magia ultrapassou o útil". A frase força uma constatação concreta. Em código com aspect bem aplicado, ler o método de domínio te diz, pelos atributos visíveis, pela injeção visível, pelo registro visível, quais aspects vão entrar em ação. Em código com aspect mal aplicado, ler o método não basta — você precisa rodar.

A consequência prática é que a quantidade aceitável de magia depende do ferramental e do time. Em equipe com IDE forte, observabilidade rica, e cultura de aspectos, o limite de magia tolerável é mais alto. Em equipe sem essas três coisas, o limite é mais baixo. Honestidade sobre onde a equipe está define qual estilo aplicar — e a maturidade profissional é saber se ajustar à equipe, não impor o estilo "puro" que funciona em outro contexto.

O quadro inteiro — o que sobrevive

Olhando para trás, dos pontos do paper de 1997 até a prática de 2026, vale articular o que sobreviveu e o que foi descartado, porque essa é a forma de fazer escolhas conscientes em projeto novo.

Sobreviveu: o vocabulário (advice, pointcut, join point, aspect — toda biblioteca AOP-like usa, mesmo sob outros nomes); o reconhecimento de cross-cutting concerns como categoria estrutural (logging, auth, transação, retry — universalmente aceitos como cross-cutting); a modularização via decorator/middleware/interceptor (presente em todo framework moderno); source generation como sucessor moderno do compile-time weaving (.NET, Go, Rust).

Foi descartado: linguagens de pointcut complexas (AspectJ "puro" virou nicho); aspectização de qualquer ponto de execução (frameworks modernos restringem deliberadamente os join points); AOP como filosofia geral ("aspectizar tudo" virou anti-padrão); ferramentas que exigiam toolchain especial (toolchain especial pesa muito).

Está em transição: proxy dinâmico vs source generator (em .NET, source gen está ganhando terreno); @Transactional via proxy vs Spring 6 com AspectJ embutido (Spring 6 lançou load-time weaving mais acessível); frameworks que misturam aspect framework com composição explícita (FastAPI Dependencies é exemplo moderno).

A engenharia que se vê hoje — em 2026 — é o resultado de quase trinta anos de seleção. Cross-cutting concerns têm vocabulário e ferramenta; a magia foi reduzida a níveis operáveis; o time pode escolher onde quer mais ou menos explicitude. Quem entende como chegamos aqui faz escolhas em código novo de forma muito mais consciente do que quem só conhece a ferramenta da moda.

Por que importa para a sua carreira

O encerramento deste módulo é o que mais aparece em entrevistas de design senior. Quando perguntam "como você organizaria cross-cutting concerns numa aplicação nova?", a resposta forte não cita ferramentas — cita critério. "Eu identificaria cada concern, classificaria pela quatro condições — universalidade, uniformidade, ortogonalidade ao domínio, estabilidade —, escolheria a camada certa por cada um (middleware, interceptor, decorator de infra, ou função explícita), e me importaria especialmente com como cada aspect vai ser observado e debugado." Em revisão de código, perceber que um filter está fazendo lógica de domínio, ou que um decorator está com sete camadas empilhadas, ou que a ordem do middleware está acidental — e propor alternativa em vocabulário maduro — é a marca clara de senior. Em pos-mortem, articular "o que falhou foi a composição dos aspects, não cada um isoladamente" muda o nível da conversa.

Mais importante: a disciplina de aspect-driven é uma generalização — a mesma habilidade de saber quando promover cross-cutting concern a aspect e quando deixar inline serve para vários contextos análogos: quando promover métodos a classes, quando extrair classes para microsserviços, quando adotar framework versus escrever próprio. O fio condutor é "entender qual dimensão de modularização paga, e qual paga menos do que cobra". Esse julgamento, mais do que qualquer ferramenta, é o que diferencia engenheiros pleno-sêniores de sêniores reais.

Como praticar

1. Auditoria de aspect-driven em projeto existente. Pegue um sistema seu e faça inventário de todos os aspects: middlewares, behaviors, filters, decorators, interceptors, source generators usados. Para cada um, articule em três frases (cross-cutting porque X, aplica via Y, leitor sabe disso porque Z). Identifique pelo menos dois aspects que falham na terceira frase — magia escondida — e proponha refatoração para tornar explícito. Esse exercício consolida o módulo inteiro.
2. Mapeamento de migração. Para um sistema legado em Spring AOP via proxy, identifique todos os @Transactional, @Cacheable, e aspects custom. Para cada um, pergunte: a chamada vem sempre via bean externo (se sim, OK), ou pode vir via this (se sim, identifique o caminho)? Proponha plano de migração para uma das três soluções (extrair método, auto-injetar, AspectJ LTW). Esse documento vira rationale para decisão arquitetural.
3. Debate sobre composição explícita versus aspect. Pegue três cross-cutting concerns recorrentes (logging, retry, validação) e implemente cada um de duas formas: via aspect framework (Polly, FluentValidation, Serilog) e via composição explícita pura (decorator manual, função wrapping, validação inline). Compare legibilidade, testabilidade, performance, debug. Documente em quais cenários você defenderia cada abordagem. Esse é o exercício que consolida julgamento profissional.