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.