3 padrões de projeto para código limpo
Strategy, Factory Method e Singleton: três padrões de projeto que evitam if-else gigante, new espalhado e recurso sem dono.
Por que isso é importante
Três padrões de projeto para código limpo no dia a dia: Strategy (comportamento plugável), Factory Method (criação centralizada) e Singleton bem delimitado. Use-os para matar if-else gigante, new espalhado e config global bagunçada — não para “aplicar GoF” no currículo.
Quando o "só mais um if" vira uma bomba-relógio no seu código
Se você já começou um projeto achando que não precisava se preocupar com arquitetura e decidiu só "subir rapidinho", provavelmente já sentiu o drama: depois de meses, aparece um mar de if-else, código repetido e cada alteração vira uma loteria de bugs.
Padrões de Design: a vacina contra a bagunça
Padrões são soluções já testadas para problemas comuns de software. Eles não inventam nada novo: só aproveitam o que já foi consagrado para evitar que você perca tempo, repita código, ou "reinvente a roda". O resultado é código extensível, limpo, fácil de testar e barato de evoluir.
Atenção
Ignorar design patterns vai te obrigar a resolver, sozinho, problemas que já foram solucionados por milhares de desenvolvedores antes de você. Adotar padrões cedo é mais barato do que remendar código quebrado depois.
Primeiro padrão: Strategy (troque o comportamento sem bagunça)
Quando usar?
Sempre que existem várias versões de um algoritmo (por exemplo, cálculo de frete, validação de pagamento...) e você acaba criando condicional gigantescas para decidir qual lógica usar, chegou a hora de aplicar o Strategy.
Como funciona?
Você separa cada variação do algoritmo em uma classe diferente e usa uma interface comum. O "contexto" (quem usa) nunca sabe qual estratégia está ativa: ele só chama a interface. A mudança ocorre em tempo de execução, sem precisar alterar o código principal.
Info
Estratégias facilitam a adição de novas regras, sem alterar o contexto principal. O maior benefício: testar cada implementação separadamente, sem impacto no fluxo geral.
Strategy: Pontos-chave
- Variações de algoritmo ficam desacopladas - Extensão sem modificar código existente - Testabilidade máxima para cada regra - Troca de comportamento em runtime
Atenção
O uso do padrão strategy pode gerar mais classes e arquivos. Planeje nomes claros e mantenha a documentação em dia!
Segundo padrão: Factory Method (controle de criação, acoplamento zero)
Quando usar?
Se você percebe que o código está lotado de "new" e switch-cases para instanciar objetos, centralize isso com o Factory Method. O cliente nunca precisa saber detalhes de cada instância concreta.
Como funciona?
Defina uma interface ou classe abstrata para o produto (por exemplo, Botão). Implemente subtipos com comportamentos distintos. Só a factory decide qual deles criar, mantendo o resto do sistema desacoplado de detalhes de implementação.
Atenção
O uso de Factory Method pode ser overkill em projetos muito pequenos. Ele brilha quando há muitos tipos de objeto, mas se seu sistema é simples, avalie antes de aplicar.
Sucesso
Com Factory Method, testar variações e trocar implementações são tarefas triviais. Você passa a controlar a evolução do projeto sem dor.
Factory Method: Pontos-chave
- Criação de objetos centralizada e desacoplada - Facilita extensão e troca de tipos - Mantém clientes ignorantes sobre tipos concretos - Diminui switch-cases espalhados
Terceiro padrão: Singleton (controle total de recurso único)
Quando usar?
Quando você precisa garantir que só existe uma instância de uma classe no sistema, como em conexões de banco, cache ou controle central de configuração.
Como funciona?
Crie um construtor privado e controle a instância por um método estático. Toda vez que requisitar, retorna sempre o mesmo objeto.
Info
Singleton é útil mas pode esconder acoplamentos perigosos e dificulta testes. Sempre considere se injeção de dependência não resolveria melhor — use singleton só para recursos 100% globais e centralizados.
Singleton: Pontos-chave
- Uma única instância em todo o sistema - Ponto de acesso global - Útil para serviços ou recursos únicos - Cuidado para não abusar e criar dependências invisíveis
Como identificar onde aplicar cada padrão no seu projeto
1. Escaneie seu projeto por condicionais gigantes: se estão trocando regras, pense em Strategy. 2. Tem "new" espalhado por todo lado? Centralize no Factory Method. 3. Precisa controlar único recurso (cache, banco, config)? Considere Singleton, mas só se necessário.
Atenção
Padrões de design não são fórmulas mágicas, nem cobertura de chocolate para todo código feio. Use quando realmente resolver problema recorrente, não porque “parece chique”.
Em resumo – O que cada padrão resolve?
- Strategy: Troca de comportamento sem confusão e sem if-else gigante. - Factory Method: Criação de objetos sem acoplamento nem repetições. - Singleton: Controla acesso único a recursos críticos do sistema.
Atenção
Antes de sair aplicando Singleton, sempre avalie se injeção de dependência não seria mais simples e testável.
Quer ir mais longe? Assista agora no Dev Doido
Quer ver exemplos práticos, debates e dúvidas respondidas sobre design patterns? Deixe seu comentário, traga seus dramas de código e confira o canal do Dev Doido no youtube para mergulhar ainda mais em arquitetura real de software.
Perguntas frequentes
Quais são os 3 padrões de projeto mais úteis no dia a dia?
Para a maioria dos times de produto: Strategy (trocar comportamento sem if-else gigante), Factory Method (centralizar criação de objetos) e Singleton controlado (um ponto único de configuração/cliente — com cuidado em testes).
Padrão de projeto ainda vale a pena com frameworks modernos?
Sim, quando reduz acoplamento e custo de mudança. O framework não elimina a necessidade de separar políticas; só muda onde o padrão aparece (hooks, services, adapters).
Singleton é anti-pattern?
Singleton global mutável costuma atrapalhar testes e concorrência. Um single instance injetado (DI) ou um cliente compartilhado com ciclo de vida claro é o uso saudável.
Como estudar padrões sem decorar GoF inteiro?
Pegue um smell real (if por tipo, new espalhado, config global) e aplique um padrão. Leia o código depois: se ficou mais fácil testar e estender, o padrão serviu.
Continue explorando
Leitura relacionada: Padrão hexagonal explicado · TypeScript com React na prática · Curso Node.js CrazyStack · Cursos CrazyStack.