Guia de Referência: Strategy (Comportamental)

Este guia orienta a aplicação do padrão Strategy em projetos de software. Objetivo: Encapsular algoritmos intercambiáveis sob um contrato comum e escolher a estratégia conforme o contexto. O padrão deve ser usado somente quando as forças do problema o justificarem.

subdirectory_arrow_right1. Problema que resolve

Uma regra varia por cliente, tipo, política ou cenário e condicionais de seleção/algoritmo estão misturadas ao fluxo principal.

subdirectory_arrow_rightSinais no código/arquitetura

• if tipo == ... escolhe fórmulas diferentes.
• Algoritmos evoluem de forma independente.
• Você quer testar regras de cálculo sem o restante do serviço.

subdirectory_arrow_right2. Quando usar

• Cálculos de preço, folha, imposto, frete, ranking, autenticação.
• Políticas selecionáveis em runtime.
• Algoritmos alternativos de ordenação/roteamento.

subdirectory_arrow_right3. Quando NÃO usar

• Quando as variantes são triviais e estáveis.
• Quando estados e transições, e não algoritmo, são o verdadeiro problema (use State).

subdirectory_arrow_right4. Estrutura e participantes

• Strategy: contrato do algoritmo.
• ConcreteStrategy: variante.
• Context: recebe/seleciona e delega.

subdirectory_arrow_right5. Procedimento de implementação

1. Extraia a parte que realmente varia.
2. Defina entradas/saídas estáveis.
3. Crie estratégias sem dependências desnecessárias.
4. Selecione no composition root ou por política explícita.
5. Evite if duplicado tanto no context quanto fora dele.

lightbulb6. Exemplo mental

OvertimeCalculator recebe OvertimeStrategy; regras 50%, 100% ou convenção coletiva são implementações separadas.

subdirectory_arrow_right7. Benefícios esperados

• OCP e testes focados.
• Troca de algoritmo sem alterar cliente.
• Reduz condicionais complexas.

subdirectory_arrow_right8. Custos e trade-offs

• Clientes/composição precisam escolher estratégia.
• Muitas estratégias pequenas podem fragmentar o código.

subdirectory_arrow_right9. Encaixe com Clean Architecture e SOLID

Estratégias de regra de negócio podem ficar no domínio/aplicação. A seleção baseada em configuração externa deve ocorrer na borda/composition root.

Regras para a IA:

• Dependa de abstrações quando a variação justificar uma fronteira.
• Não faça o domínio importar SDKs, frameworks, banco de dados ou UI.
• Mantenha cada participante com responsabilidade coesa.
• Prefira composição quando ela reduzir acoplamento; não crie hierarquias artificiais.
• Registre a decisão arquitetural quando o padrão afetar muitos módulos.

subdirectory_arrow_right10. Caminho de refatoração

Ideal para switches repetidos sobre tipo de cálculo/política.

Ao refatorar um sistema existente:

1. Proteja o comportamento atual com testes.
2. Faça passos pequenos e reversíveis.
3. Introduza primeiro a abstração/contrato.
4. Migre um fluxo por vez.
5. Remova código antigo apenas após equivalência comportamental comprovada.

fact_check11. Estratégia de testes

Teste cada estratégia com tabela de casos e o seletor separadamente. Use testes de propriedade quando fórmulas forem complexas.

Checklist mínimo:

• caminho feliz
• entradas/estados de limite
• erros e falhas de dependências
• comportamento de cada implementação concreta
• teste de contrato quando houver múltiplas implementações
• teste de integração apenas onde a fronteira externa for relevante

subdirectory_arrow_right12. Padrões relacionados

• State
• Template Method
• Factory Method

subdirectory_arrow_right13. Perguntas de diagnóstico para a IA

1. Qual aspecto do sistema realmente varia?
2. Essa variação já está causando duplicação, condicionais ou acoplamento?
3. Uma função/composição simples resolveria com menos abstrações?
4. O padrão reduz o custo de uma mudança concreta que já é provável?
5. Qual é o custo de introduzir novas classes, indireção e configuração?
6. Como a decisão será testada e observada em produção?

smart_toy14. Prompt pronto

Você é o arquiteto do projeto. Avalie se o padrão **Strategy** é adequado para o problema abaixo.

Contexto: [DESCREVA o sistema, stack/arquitetura, estado atual e o problema observado]
Objetivo: [DESCREVA o resultado esperado ao avaliar ou aplicar este padrão]
Restrições: [DESCREVA prazo, legado, performance, testes, compatibilidade e o que não pode mudar]

Antes de codificar:
1. Identifique as forças que justificam ou rejeitam Strategy.
2. Compare pelo menos uma alternativa mais simples e um padrão relacionado (State, Template Method, Factory Method).
3. Se o padrão for justificado, mostre participantes, dependências e fluxo.
4. Preserve Clean Architecture/SOLID: regras centrais não dependem de infraestrutura.
5. Implemente incrementalmente, com testes.
6. Ao final, liste trade-offs e sinais de overengineering.

Não aplique o padrão apenas porque foi solicitado; rejeite-o se não houver variação/complexidade que o justifique.

helpComo preencher os campos

• Contexto: descreva o tipo de sistema, stack/versões, arquitetura atual, onde a mudança acontece e o comportamento relevante já existente.
• Objetivo: descreva o resultado observável que deve existir ao final, não apenas a tecnologia que você quer usar.
• Restrições: informe o que não pode mudar, compatibilidade, prazo, segurança, acessibilidade, performance, legado, dependências e limites de escopo.

lightbulbExemplo preenchido

Contexto: Folha de pagamento possui regras diferentes de cálculo de hora extra por categoria de empregado.
Objetivo: Trocar o algoritmo de cálculo conforme o contexto sem switches repetidos.
Restrições: Cada estratégia deve obedecer ao mesmo contrato; não criar estratégia para variação inexistente.

subdirectory_arrow_right15. Critério de aceite

A aplicação de Strategy só está concluída quando:

• o problema que motivou o padrão está explicitamente documentado;
• o código cliente depende do contrato correto, não de detalhes acidentais;
• adicionar a variação-alvo exige menos mudanças que antes;
• testes protegem a extensão/refatoração;
• não houve vazamento de infraestrutura para o núcleo;
• a solução ficou mais compreensível para manutenção, não apenas “mais orientada a padrões”.

subdirectory_arrow_right16. Base Conceitual e Relações

• Catálogo Refactoring.Guru em português — escopo de 22 padrões.
• Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson e Vlissides) — intenção, aplicabilidade, participantes, consequências e relações entre padrões.
• Guias de Clean Architecture, princípios de design, refatoração e código limpo deste pacote.