Design Patterns: como eles podem transformar seu código

Introdução

Já se perdeu em um código cheio de if e else e pensou: “tem que existir um jeito melhor de fazer isso”?

Pois é, esse é o tipo de situação que os Design Patterns (ou Padrões de Projeto) vieram resolver.

À medida que você evolui como desenvolvedor, começa a perceber que muitos dos desafios que enfrenta não são novos. É justamente aí que os Design Patterns entram: como soluções testadas e comprovadas para problemas que se repetem no desenvolvimento de software.

Resumo rápido

• Os Design Patterns foram catalogados no livro “Design Patterns: Elements of Reusable Object-Oriented Software” (Addison-Wesley, 1994), escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, o grupo conhecido como Gang of Four.
• O livro reúne 23 padrões divididos em três grupos: 5 criacionais (como Singleton e Factory), 7 estruturais (como Adapter e Facade) e 11 comportamentais (como Observer e Strategy).
• Não são bibliotecas para instalar nem regras fixas. São soluções de projeto já documentadas que você adapta ao contexto do seu sistema.

O que são Design Patterns?

De forma simples, Design Patterns são modelos práticos para resolver problemas recorrentes de forma elegante e organizada.

Eles não são “regras fixas” ou bibliotecas que você instala. Na verdade, são maneiras de pensar o código.

Em vez de reinventar a roda toda vez, você pode aplicar soluções que já foram testadas, documentadas e refinadas por décadas de programadores. É como ter um manual de boas práticas que ajuda a evitar os erros mais comuns no desenvolvimento.

Se você quer entender como esse raciocínio se aplica em escala maior, vale ler também sobre Arquitetura Limpa, que usa uma lógica parecida para organizar sistemas inteiros, não só classes isoladas.

Quem criou os Design Patterns?

Os padrões mais conhecidos foram catalogados por quatro autores, conhecidos como Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Eles publicaram o livro “Design Patterns: Elements of Reusable Object-Oriented Software” pela Addison-Wesley em 1994.

A grande sacada desses autores foi perceber que, embora cada projeto seja único, os problemas de projeto se repetem. Por isso eles documentaram 23 padrões, agrupados em criacionais (como lidar com a criação de objetos), estruturais (como organizar classes e objetos maiores) e comportamentais (como objetos se comunicam entre si).

Para explorar cada um desses 23 padrões com exemplos em várias linguagens, o site Refactoring Guru é uma referência gratuita bastante usada pela comunidade.

O objetivo dos Design Patterns

O principal objetivo dos Design Patterns é organizar o código de forma que ele cresça sem virar uma bagunça. Eles ajudam a manter o sistema coeso e fácil de evoluir.

Eles ajudam a:

• Tornar o sistema modular e escalável
• Reduzir o acoplamento entre partes do código
• Facilitar a manutenção e o reaproveitamento
• Melhorar a comunicação entre desenvolvedores

Por exemplo, quando alguém diz “usei o padrão Singleton”, todo programador entende imediatamente o que aquilo significa. É uma linguagem comum entre profissionais, parecida com a que aparece em discussões sobre DevOps e profissionalismo no dia a dia do time.

Quando usar Design Patterns?

Nem todo código precisa de um padrão. No entanto, há sinais claros de que está na hora de aplicar um.

1. Problemas recorrentes

Se você repete a mesma solução em vários lugares do código, um padrão pode centralizar isso.

Exemplo: se você cria objetos parecidos em vários pontos do sistema, um Factory pode centralizar essa criação.

2. Dificuldade de manutenção

Seu sistema cresce e começa a parecer um espaguete? Nesse caso, os padrões ajudam a dividir responsabilidades, deixando cada classe cuidar apenas do que precisa.

3. Acoplamento excessivo

Quando uma mudança em um arquivo quebra outros cinco, há dependências demais. Nessas situações, o Observer, por exemplo, ajuda a avisar outros módulos sobre algo sem que eles dependam diretamente uns dos outros.

4. Comunicação entre devs

Usar padrões conhecidos é como falar uma linguagem universal. Se alguém lê “Strategy Pattern”, já sabe que o comportamento do sistema é trocável dinamicamente, sem precisar ler a implementação inteira para entender a intenção.

Exemplos práticos de Design Patterns

Sem entrar em código ainda, veja três padrões que aparecem o tempo todo.

1. Singleton

Garante que só exista uma instância de uma classe. É útil para conexões com banco de dados, cache ou serviços globais que não fazem sentido duplicar.

Exemplo prático: sua aplicação cria e reaproveita uma única conexão com o banco em todo o sistema, em vez de abrir uma conexão nova a cada requisição.

2. Observer

Permite que múltiplos objetos observem outro objeto e reajam automaticamente a mudanças nele. Dessa maneira, o sistema fica mais flexível e desacoplado.

Exemplo prático: em um sistema de pedidos, quando o status muda de “processando” para “enviado”, o sistema notifica o cliente automaticamente e atualiza o painel, sem depender de código duplicado espalhado pelo projeto.

3. Factory

Centraliza a criação de objetos de diferentes tipos sem precisar alterar o código que os utiliza. Assim, fica mais fácil adicionar novos tipos de objetos no futuro.

Exemplo prático: um sistema de pagamento com cartão, boleto e Pix pode usar uma Factory para escolher qual classe criar, sem que o restante do código precise conhecer os detalhes de cada meio de pagamento. Se você quiser praticar isso em um projeto real antes de aplicar padrões mais elaborados, o guia para criar sua primeira API REST com Go é um bom ponto de partida.

Sinais de que você precisa de um Design Pattern

• Você está repetindo o mesmo código em vários lugares
• Seu sistema é difícil de modificar sem quebrar outras partes
• Você quer adicionar novas funções com o mínimo de impacto no que já existe
• Seu código está muito dependente entre módulos

Se você reconheceu algum desses sinais, é hora de começar a pensar em padrões.

Perguntas frequentes

Design Patterns servem só para linguagens orientadas a objetos?

Os 23 padrões do livro da Gang of Four foram descritos em um contexto orientado a objetos, mas a ideia por trás deles (nomear e reaplicar soluções conhecidas para problemas recorrentes) aparece também em linguagens funcionais e multiparadigma, ainda que com nomes ou implementações diferentes.

Qual a diferença entre um Design Pattern e um framework?

Um framework é código pronto que você importa e usa. Um Design Pattern é uma forma de organizar o seu próprio código para resolver um problema específico. Você pode aplicar um Singleton ou um Observer sem depender de nenhuma biblioteca externa.

Preciso decorar os 23 padrões da Gang of Four para ser um bom programador?

Não. A maioria dos desenvolvedores usa no dia a dia um punhado deles (Singleton, Factory, Observer e Strategy aparecem com bastante frequência). O importante é reconhecer o problema e saber que existe uma solução catalogada, não memorizar os 23 de cor.

Por onde começar a estudar Design Patterns na prática?

Um bom caminho é pegar um problema real do seu próprio código, identificar qual das categorias (criacional, estrutural ou comportamental) ele se encaixa e procurar o padrão correspondente no livro original ou no site Refactoring Guru antes de tentar aplicar de memória.

Conclusão

Usar Design Patterns não é sinal de código “bonito”, é sinal de código pensado. Eles não são uma fórmula mágica, mas sim ferramentas que ajudam você a pensar e a crescer como desenvolvedor.

Ao aplicá-los, você escreve um código mais organizado, mais fácil de entender e muito mais fácil de evoluir.

Em resumo, entender Design Patterns é o primeiro passo para escrever códigos mais limpos. Se você quer ir além e estruturar sistemas que realmente duram, vale a leitura de Arquitetura Limpa: a planta baixa para softwares que duram.