Padrões de projeto não são fórmula mágica
Achei que entender o livro padrões de projeto ia resolver meus problemas de arquitetura. Resolveu alguns. Criou outros. Vou ser direto: o livro do GoF (Gang of Four) é referencial, não um manual de receitas. A maioria dos desenvolvedores lê os padrões de forma superficial e depois os aplica no lugar errado, gerando código mais complexo do que o problema original. O padrão Strategy é o que mais vejo sendo usado de forma errada. A ideia é trocar o algoritmo em tempo de execução. Na prática, vejo gente criando interfaces para cada variationzinha que já tinha três linhas de código. Isso não é estratégia, é overengineering disfarçado.
O que realmente importa no livro padrões de projeto
O que separa quem usa bem padrões de quem só decorou nomes é entender o problema que cada padrão resolve, não a solução em si. O padrão Observer, por exemplo, não serve para tudo que tem "algo que acontece quando outra coisa acontece". Ele serve quando você tem dependência um-para-muitos e precisa de desacoplamento entre o sujeito observado e os observadores. Se você pode usar um evento simples do framework, não precise implementar o padrão completo com lista de observadores, notify, attach, detach e tal. O padrão existe para problema real aparece, não para prevenir problemas hipotéticos. O Singleton é o padrão mais mal empregado que existe. Eu já passei uma semana caçando um bug onde dois singletones criavam instâncias diferentes porque oClassLoader do Tomcat carregou a classe duas vezes em contextos diferentes. A solução foi remover o Singleton e usar injeção de dependência com escopo de aplicação. Se alguém te disser que Singleton é essencial, pergunte qual problema específico ele está resolvendo no contexto atual. Geralmente a resposta não sustenta.
Como estudar padrões de forma útil
Ler o livro de cima para baixo não funciona bem. A estrutura clássica apresenta o padrão, mostra a classe, fala quando usar, quando não usar, e dá exemplos em C++ ou Smalltalk. O problema é que os exemplos são abstratos demais para o dia a dia. O que funcionou para mim foi olhar para o código existente no projeto e tentar identificar quais padrões já estavam sendo usados, mesmo que sem nome próprio. Quando você encontra um método que tem cinco condicionais if/else para comportamento diferente, pensa: isso é um Strategy esperando para ser extraído. Quando vê que uma classe cria objetos de outras classes com new diretamente, pensa em Factory Method ou Abstract Factory. A chave é reconhecê-los na natureza antes de tentar aplicá-los intencionalmente.
Uma coisa que poucos mencionam: padrões de criação, estruturais e comportamentais são uma divisão didática, não uma lei da física. No código real, um único módulo costuma usar três ou quatro padrões diferentes entrelaçados. O Facade escondendo Composite por trás de uma interface simples, com Builder montando os objetos internos. Tentar classificar cada trecho em uma categoria é perda de tempo. O que importa é se o código está comunicando intenção claramente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando padrões pioram o código
Vou listar situações onde aplicar padrões é ruim: Projetos pequenos com menos de mil linhas. A overhead de abstrações supera qualquer benefício. Um if bem escrito vale mais que dez padrões.
Quando você não entende o problema suficiente ainda. Aplicar padrão antes de dominar o domínio é como montar móveis sem ler o manual. No final sobram peças e o móvel balança. Quando o padrão é aplicado por vaidade técnica. Já vi code review reprovado só porque o desenvolvedor não usou Decorator quando poderia ter usado uma herança simples. O código ficou mais difícil de ler e mais fácil de quebrar.
Eu tive um caso específico com o padrão Chain of Responsibility. Precisei implementar uma validação em cadeia onde cada validador verificava um aspecto diferente de um formulário. A implementação inicial ficou perfeita no papel. O problema era que adicionar um novo validador significava modificar a cadeia inteira, o que violava o princípio aberto-fechado na prática. A solução que encontrei foi usar uma lista de beans registrados no Spring e deixar o framework encadear a execução, removendo a responsabilidade manual do encadeamento. Ganhei desacoplamento real e perderi complexidade desnecessária.
Alternativas ao livro clássico
Se você já leu o GoF e sentiu que não conseguia aplicar na prática, o Head First Design Patterns é mais acessível mas ainda assim tem exemplos em Java antigo. Para quem programa em linguagens modernas, Design Patterns in Modern C++ ou artigos sobre patterns em Kotlin/TypeScript podem ser mais relevantes. O conceito é o mesmo, mas a sintaxe e os recursos da linguagem mudam como você aplica. Também vale dar uma olhada em anti-patterns. Conhecer o que é errado às vezes ensina mais do que ler sobre o certo. O livro "AntiPatterns" do Brown et al. é viejo mas ainda relevante. E tem o site refactoring.guru que traz exemplos visuais práticos, embora seja mais introdutório do que profundo.
O que eu faria diferente se começasse agora: em vez de ler o livro todo de uma vez, pegaria um padrão por semana, implementaria em um projeto pequeno e deixaria descansar. Depois de três semanas com três padrões dominados, voltaria e tentaria identificar padrões no código alheio. A aplicação prática é o que fixa o conhecimento, não a leitura passiva. Se quiser baixar uma versão do livro padrão, existem edições em português traduzidas pela Editora Bookman e pela Caelum. A tradução da Caelum é mais fiel ao original e usa exemplos em Java, que ainda é a linguagem mais próxima dos exemplos originais em C++. A da Bookman também é aceitável mas tem alguns trechos que ficaram confusos na tradução.
