React
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.
Padrões de DesignCódigo Limpo
Carregando
Strategy, Factory Method e Singleton: três padrões de projeto que evitam if-else gigante, new espalhado e recurso sem dono.
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.
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 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.
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.
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.
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.
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.
- Variações de algoritmo ficam desacopladas - Extensão sem modificar código existente - Testabilidade máxima para cada regra - Troca de comportamento em runtime
O uso do padrão strategy pode gerar mais classes e arquivos. Planeje nomes claros e mantenha a documentação em dia!
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.
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.
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.
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.
- 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
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.
Crie um construtor privado e controle a instância por um método estático. Toda vez que requisitar, retorna sempre o mesmo objeto.
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.
- 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
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.
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”.
- 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.
Antes de sair aplicando Singleton, sempre avalie se injeção de dependência não seria mais simples e testável.
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.
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).
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 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.
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.
Leitura relacionada: Padrão hexagonal explicado · TypeScript com React na prática · Curso Node.js CrazyStack · Cursos CrazyStack.