Existe um momento muito específico em qualquer code review em que alguém pergunta "por que isso é uma factory?" e a resposta é um silêncio incômodo, seguido de "porque estava assim em um exemplo que eu vi". Esse momento é a prova de que os padrões de projeto estão sendo usados ao contrário. Não para resolver um problema. Para dar a impressão de que um problema está sendo resolvido.
Este artigo não é uma lista de padrões de projeto com a definição de livro. Essa lista já existe, foi escrita pela Gangue dos Quatro há trinta anos e continua circulando como se fosse dogma. A pergunta que importa em 2026 é quais padrões ganham seu lugar no código e quais estão ali só para o projeto parecer sofisticado, não quais padrões existem.
Strategy: o padrão de projeto que se nota quando falta
Strategy é um dos poucos padrões de projeto que quase nunca sobra. A razão é simples: ele resolve um problema que aparece o tempo todo em sistemas reais: ter várias formas de fazer a mesma coisa e precisar alternar entre elas sem reescrever quem as usa.
Um exemplo típico: um sistema de precificação que calcula descontos diferentes conforme o tipo de cliente, a região ou a campanha ativa. Sem Strategy, essa lógica termina em um método com quinze `if` aninhados que cresce toda vez que o marketing lança uma promoção nova. Com Strategy, cada regra de desconto é sua própria classe, implementa a mesma interface, e o código que as usa não sabe nem se importa com qual está rodando.
O sinal de que Strategy vale a pena é o comportamento intercambiável já existir no domínio, não na sua cabeça. Se hoje você tem três formas reais de calcular algo e sabe que vai ter uma quarta no mês que vem, Strategy poupa um refactor doloroso. Se você tem uma única implementação e a envolve em uma interface "para o caso de depois surgir outra", está pagando o custo da abstração antes de precisar dela. Isso é medo de decidir, disfarçado de padrão de projeto, não de estratégia.
Observer: para eventos que existem, não para os que você imagina
Observer tem má fama porque é mais usado errado do que certo. A versão correta: existe um evento genuíno no sistema, algo acontece e várias partes do código precisam reagir sem que quem dispara o evento saiba quem está ouvindo. Um pedido é confirmado e isso dispara uma notificação, a atualização do estoque e o registro em analytics. Nenhuma dessas três coisas precisa saber das outras. Isso é o Observer fazendo o trabalho dele.
A versão que sobra: alguém coloca um `EventEmitter` entre duas classes que na verdade têm uma relação direta e previsível, porque "assim fica mais flexível". A flexibilidade que ninguém pediu é a forma mais cara de dívida técnica, porque não parece dívida. Parece boa arquitetura até alguém precisar rastrear um bug ao longo de uma cadeia de eventos que salta entre seis arquivos, sem nenhum stack trace útil.
Os padrões de projeto baseados em eventos multiplicam a dificuldade de debugging por natureza. Isso é aceitável quando o desacoplamento que eles trazem justifica esse custo. É uma má decisão quando o problema real era uma chamada de função direta e alguém a transformou em uma arquitetura orientada a eventos porque ficava melhor no diagrama.
Factory: só se a criação de objetos realmente varia
Factory é provavelmente o mais citado e o mais mal aplicado de todos os padrões de projeto clássicos. A ideia original é legítima: quando construir um objeto envolve lógica não trivial, decidir entre subtipos, ou depender de configuração externa, centralizar essa construção evita duplicar a decisão em vinte lugares do código.
O problema é que Factory virou reflexo. Qualquer `new` dentro de uma função dispara o alarme de "isso precisa de uma factory" na cabeça de quem leu o livro mas não olhou o contexto. O resultado é um conjunto de bases de código com `UserFactory`, `OrderFactory` e `ConfigFactory` que fazem exatamente uma coisa: chamar o construtor com os mesmos argumentos que receberam. Essa camada extra não traz abstração real: alguém precisa atravessá-la para entender o que o código faz, sem receber nada em troca.
A pergunta que separa uma Factory útil de uma decorativa é simples: a lógica de construção varia de verdade, conforme tipo, ambiente ou configuração? Se a resposta é sim, a Factory vale o custo. Se a resposta é "não, mas fica com uma cara mais profissional assim", esse código vai sobreviver no repositório por anos, sem que ninguém tenha coragem de apagá-lo, gerando a sensação de complexidade sem nenhum dos seus benefícios.
Por que o livro de padrões de projeto virou uma desculpa
O livro original de padrões de projeto resolvia um problema da sua época: linguagens com pouco suporte a composição, sem funções de primeira classe, sem as ferramentas que hoje são padrão. Muitos desses padrões eram, basicamente, remendos para as limitações da linguagem. Strategy e Command, em boa parte, deixam de ser necessários quando a linguagem permite passar funções diretamente. Um objeto Command que encapsula uma única operação é, na maioria dos stacks modernos, uma função com mais formalidade.
Mas o livro virou cânone, e o cânone virou sinal de status. Em uma entrevista técnica, mencionar padrões de projeto soa a experiência. Em um code review, colocar um Decorator onde bastava uma função soa a rigor. O problema é que esse rigor é de fachada. Não resolve nada que já não estivesse resolvido de forma mais simples. Só adiciona camadas que precisam ser aprendidas, mantidas e explicadas para o próximo que chegar.
Um sênior de verdade não se mede por quantos padrões de projeto reconhece no código do outro. Se mede por saber quando um problema não precisa de nenhum. Isso é mais difícil de demonstrar em uma entrevista de uma hora, mas é o que realmente separa a experiência da memorização.
O over-engineering não parece over-engineering
Ninguém escreve código complicado demais pensando "vou complicar isso aqui". A pessoa se convence de que está sendo cuidadosa, previdente, profissional. Os padrões de projeto são o veículo perfeito para esse autoengano porque têm nome, têm respaldo bibliográfico, e soam a boa prática mesmo quando não resolvem nada concreto.
O teste real de um padrão de projeto é se, ao removê-lo, o código fica mais difícil de escrever ou de ler, não se ele aparece no livro. Se Strategy desaparece e o código continua igual de claro com um `if`, então Strategy sobrava. Se Observer desaparece e já não é preciso rastrear eventos fantasmas, Observer era o problema, não a solução. Se Factory desaparece e ninguém sente falta da camada intermediária, então Factory nunca deveria ter existido.
As equipes que produzem código sustentável ao longo do tempo não são as que conhecem mais padrões de projeto. São as que resistem à tentação de usá-los quando não é necessário. Isso exige mais confiança técnica do que aplicar o padrão, não menos. Qualquer um pode copiar uma estrutura do livro. É preciso critério de verdade para olhar para um problema simples e deixá-lo simples, mesmo sabendo que existe uma forma mais "elegante" de complicá-lo.
A posição final
Padrões de projeto não são boas práticas por definição. São ferramentas, e como toda ferramenta, seu valor depende exclusivamente do problema que têm pela frente. Strategy quando existe um comportamento que muda de verdade. Observer quando acontecem eventos que realmente importam para várias partes do sistema. Factory quando construir um objeto de fato tem lógica por trás. Fora desses casos, são ruído com prestígio.
Da próxima vez que alguém propuser colocar um padrão de projeto em um PR, a pergunta certa é: "o que acontece se a gente não usar?", não "está bem aplicado segundo o livro?". Se a resposta é "nada, o código continua igual de claro", aí está a resposta. O padrão não conquistou seu lugar. Só se infiltrou.
