Como você escolhe o padrão certo para um problema?

Question

Accepted Answer

Escolher o **padrão certo** (ou nenhum) para um problema requer entender o problema profundamente, conhecer os padrões e seus trade-offs, e aplicar julgamento para equilibrar benefícios contra complexidade. O objetivo é resolver o problema bem, não usar padrões pelo simples fato de usá-los.

## Comece com o problema, não com o padrão

```text
✓ UNDERSTAND THE PROBLEM first → what's the actual issue? (don't start by picking a pattern)
✓ Identify what you NEED → flexibility? decoupling? extensibility? simpler creation?
✓ Then ask: does a pattern address THIS problem well? (or is a simple solution better?)
→ problem-first, not pattern-first → avoid forcing patterns
```

## Mapeie padrões para problemas

```text
Recognize which patterns fit which problems:
  → need ONE instance? → Singleton (or DI/module — consider alternatives)
  → decouple object creation? → Factory; complex construction? → Builder
  → swappable algorithms / eliminate conditionals? → Strategy
  → notify many of changes? → Observer; add behavior by wrapping? → Decorator
  → incompatible interfaces? → Adapter; simplify a subsystem? → Facade
  → undo/queue actions? → Command; control access? → Proxy
→ know the patterns' INTENT (the problem each solves) to recognize the fit
```

## Aplique julgamento

```text
✓ Weigh BENEFITS vs COMPLEXITY → does the pattern's value justify its added structure?
✓ Prefer SIMPLICITY → the simplest solution that works (patterns add complexity)
✓ Consider ALTERNATIVES → language features, simpler approaches, other patterns
✓ Don't OVER-ENGINEER (YAGNI) → don't add patterns for hypothetical future needs
✓ Patterns often EMERGE via refactoring → recognize when code would benefit, then apply
→ the RIGHT choice solves the problem well with appropriate (not excessive) complexity
```

## Por que isso importa

Entender como escolher o padrão certo é um conhecimento valioso em nível sênior porque **aplicar padrões bem requer julgamento** — saber qual padrão se encaixa em qual problema e quando usar um padrão versus uma solução mais simples — então é a habilidade prática que torna o conhecimento de padrões útil.

Conhecer padrões não é suficiente; a habilidade é escolher o certo (ou nenhum) para um problema específico, e este julgamento é o que distingue o uso efetivo de padrões.

Entender **começar com o problema, não com o padrão** — entender profundamente o problema real e identificar o que você precisa (flexibilidade, desacoplamento, extensibilidade), depois questionar se um padrão o aborda bem ou se uma solução mais simples é melhor — reflete a abordagem orientada ao problema que evita forçar padrões (um erro comum).

Entender como **mapear padrões para problemas** — reconhecer quais padrões se encaixam em quais necessidades (Singleton para uma instância, Factory/Builder para criação, Strategy para algoritmos intercambiáveis, Observer para notificações, Adapter para interfaces incompatíveis, Facade para simplificação, Command para ações, Proxy para controle de acesso) conhecendo a **intenção** de cada padrão (o problema que ele resolve) — é o conhecimento prático que permite reconhecer quando um padrão se encaixa.

Entender **aplicar julgamento** — pesando benefícios contra complexidade (o valor justifica a estrutura adicional?), preferindo simplicidade (a solução mais simples que funciona, já que padrões adicionam complexidade), considerando alternativas (recursos da linguagem, abordagens mais simples), evitando over-engineering (não adicionando padrões para necessidades futuras hipotéticas — YAGNI), e reconhecendo que padrões frequentemente emergem através de refatoração — reflete o julgamento maduro que produz bons designs.

O insight chave é que a escolha certa resolve o problema bem com complexidade apropriada, não excessiva.

Como aplicar padrões bem requer o julgamento de escolher o certo (ou nenhum) para um problema — entender o problema, mapear padrões por sua intenção, e equilibrar benefícios contra complexidade enquanto se prefere simplicidade — e como este julgamento é o que torna o conhecimento de padrões praticamente útil (versus aplicar excessivamente padrões), entender como escolher o padrão certo é um conhecimento valioso em nível sênior — o julgamento prático que torna o conhecimento de padrões útil, enfatizando pensamento orientado ao problema, mapeamento de padrões por intenção, e equilíbrio de benefícios contra complexidade, e refletindo o senso de design maduro (resolver problemas bem com complexidade apropriada, não usar padrões pelo simples fato de usá-los) que distingue desenvolvedores sênior.