Skip to content

Design Patterns (Padrões de Projeto)

Design Patterns são soluções generalizadas e reutilizáveis para problemas comuns que ocorrem no design de software. Eles não são pedaços de código prontos, mas sim modelos de como resolver um problema.


1. Categorias de Padrões

No desenvolvimento Web com TypeScript/React, focamos em alguns padrões específicos das três categorias clássicas (GoF):

A. Criacionais (Como criar objetos)

  • Factory: Usamos funções de fábrica para criar objetos complexos ou entidades de domínio sem expor a lógica de criação. Veja mais em POO.
  • Singleton: Usado para serviços globais que devem ter apenas uma instância (ex: um cliente de Analytics ou um serviço de Cache).

B. Estruturais (Como organizar classes e objetos)

  • Adapter: Usado para converter a interface de uma biblioteca externa para um formato que nossa aplicação entenda. Se trocarmos a biblioteca, mudamos apenas o Adapter.
  • Decorator/HOC: No React, usamos High Order Components ou Composições para adicionar funcionalidades a componentes existentes.

C. Comportamentais (Como os objetos se comunicam)

  • Observer: Base de como o Redux e o TanStack Query funcionam. O sistema "observa" mudanças no estado e notifica os interessados (componentes).
  • Strategy: Usado para alternar algoritmos ou comportamentos em tempo de execução (ex: diferentes estratégias de cálculo de impostos dependendo do estado do paciente).

2. Padrões Específicos de React

Além dos padrões clássicos, o ecossistema React possui seus próprios padrões:

  • Compound Components: Componentes que trabalham juntos para gerenciar estado compartilhado (ex: Select e Option).
  • Render Props: Técnica para compartilhar código entre componentes usando uma prop cujo valor é uma função.
  • Custom Hooks: A forma moderna e preferida de encapsular e reutilizar lógica de estado.

3. Por que usar?

  1. Linguagem Comum: Quando você diz "usei um Factory aqui", outros desenvolvedores seniores entendem imediatamente a intenção do código.
  2. Reutilização: Evita "reinventar a roda" para problemas que já possuem soluções otimizadas.
  3. Desacoplamento: Padrões como Adapter e Strategy permitem que o sistema mude sem quebrar tudo.

Como fazer vs Como não fazer

✅ Como fazer

  • Use Custom Hooks para lógica de UI.
  • Use Adapters para isolar bibliotecas externas (ex: Axios, Firebase) do restante do código.
  • Prefira Composição sobre Herança.

❌ Como não fazer

  • Aplicar padrões complexos para problemas simples (over-engineering). Se um if resolve, você não precisa de um Strategy.
  • Forçar o uso de padrões de POO clássica (como Singleton com classes) onde um objeto literal simples do JS resolveria melhor.