Escolhendo o livro certo de design patterns
O Design Patterns do GoF (Gamma, Helm, Johnson, Vlissides) continua sendo a referência principal, mas a tradução para português que circula pela editora Bookman tem alguns trechos péssimos de localização. Termos como "hook" viraram "gatilho" quando o sentido técnico era completamente outro. Eu caí nessa armadilha nos anos 2000 e perdi semanas tentando entender um padrão que, no original, era trivial. Se você lê em português, a versão da Pearson Brasil (ISBN 978-8543027985) é a mais aceitável, mas recomenda-se consultar o original em inglês paralelamente para os padrões mais complexos como Visitor e Interpreter.
design patterns livro guia prático
Eu comecei a estudar esses padrões em 2003 trabalhando em um sistema legado de folha de pagamento. O código tinha uma herança em cascata com mais de 47 classes especializadas de cálculos salariais, cada uma com seu próprio método compute() sobrecarregado de forma inconsistente. Um novo requisito regulatório exigia adicionar regras de retenção de IR sem reescrever tudo. Usei Visitor nesse projeto. A adaptação levou uns três dias de refactor, mas evitou uma mudança de duas semanas em cada classe filha. Não adianta decorá-los. A maioria dos desenvolvedores estuda o catálogo inteiro de 23 padrões e depois esquece 80% na prática porque nunca criou contexto real para aplicá-los. O jeito certo é: pegue um problema concreto do seu trabalho atual, identifique a dor de manutenção, e aí busque no catálogo o padrão que se encaixa. Comece por Strategy, Factory Method e Observer. Eles cobrem cerca de 60% dos problemas do dia a dia.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um erro que vejo todo mundo cometer é aplicar Abstract Factory quando um simples construtor com parâmetros resolveria. Ou usar Chain of Responsibility para encadear três validações simples. O padrão existe para dar flexibilidade a cenários dinâmicos, não para deixar o código mais bonito visualmente. Se você pode trocar um comportamento em tempo de execução sem recompilar, aí sim faz sentido o padrão. Senão, tá só complicando. O livro do Eric Freeman e Elisabeth Robson (Head First Design Patterns, também traduzido) é melhor para iniciantes. A abordagem visual ajuda muito, mas o aprofundamento técnico é rasa para quem já trabalha com Java há anos. Eu recomendo ler o Head First primeiro e depois o GoF como consulta, não como leitura linear.
Tem ainda o "Design Patterns em C++" do Jon Botting, menos conhecido mas com exemplos que abordam questões de memória e RAII que o GoF não cobre. Se sua stack é Cou Java, o GoF em si já basta na maioria dos casos. O padrão Command é subutilizado. Quase todo mundo conhece, mas só usa em cases óbvios de undo/redo. Em sistemas de fila assíncrona, ele resolve um monte de dor sem ninguém perceber. Eu vi um time inteira uma camada de integração com microsserviços usando Command com serialização JSON. Quando o contrato da API mudou, eles isolaram a transformação em um único lugar ao invés de caçar chamadas espalhadas por 30 classes.
Sem contar que o GoF foi escrito em 1994 para Smalltalk. Alguns padrões como Composite eFlyweight têm overhead desnecessário em linguagens modernas com garbage collection agressivo. Não tenha religião por eles. Use o que funciona no seu contexto.
