Pular para o conteúdo
thiagoetipadrões

Contatos

apps/service-design/strategy-pattern

162 · Padrões de Design de Serviço · ≈ 5 min de estudo

Strategy

Cada forma de liquidar um pagamento vira uma classe com a mesma interface; o contexto guarda uma delas, pede o plano e o entrega ao trilho, sem nunca olhar qual método está segurando. Trocar de algoritmo é trocar o objeto. Use quando o mesmo problema tem várias soluções escolhidas de fora — pelo cliente, pela configuração — e cada uma tem regras próprias.

passos
5
arquivos
3
testes
0
tecnologias
4
Lógica puraTypeScriptBunElysiaStryker
CenárioRelaçõesComparar
Baixar cartão

Cenário

A fintech de pagamentos liquida por PIX, TED ou boleto, conforme o cliente escolhe. Cada trilho tem regra própria: PIX é instantâneo e sem tarifa, mas limitado a R$ 1.000,00 por transação entre 20h e 6h; TED cobra R$ 10,90 e só liquida em dia útil entre 06h30 e 17h — fora disso, na abertura do próximo dia útil; boleto cobra R$ 3,50 e vence em três dias. O contexto de pagamento não conhece nenhuma dessas regras.

Planta

Fluxo
7/7
Cliente escolhe o metodostrategySettlementForContextPaymentstrategySetInterfaceStrategySettlementPixtarifa 0, limite noturnoTEDtarifa 10,90,janela 06h30-17hBoletotarifa 3,50,vencimento D+3Trilhos HTTPplanPOST/rails/:rail/instructions
7

7 passos — reproduza para seguir o fluxo

Como funciona

5 passos

Algoritmos trocáveis por uma interface.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    InterfaceStrategySettlement tem um único método, plan(pagamento, agora), que devolve tarifa e momento de liquidação

  2. 02

    StrategySettlementPix, StrategySettlementTed e StrategySettlementBoleto implementam cada algoritmo; recusa lança ErrorSettlementRefused

  3. 03

    strategySettlementFor(método) resolve a escolha do cliente num mapa — a fábrica decide "qual", a estratégia decide "como"

  4. 04

    ContextPayment recebe a estratégia no construtor, troca com strategySet e só delega: pede o plano e envia ao trilho

  5. 05

    O relógio é injetado no contexto, então janela e limite noturno são testados em horários exatos

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Contexto sem switch por método

  • Novo método é uma classe e uma entrada no mapa

  • Cada algoritmo testável sozinho, na fronteira

  • Troca em runtime sem reconstruir o contexto

Custos

  • Uma classe por variação, mesmo as pequenas

  • Interface mínima limita o que cada estratégia recebe

  • Quem escolhe precisa conhecer as estratégias

  • Variação única não justifica a abstração

apps/service-design/strategy-pattern

3 arquivos

src/

  • strategy_settlement.tsInterface, as três estratégias e a fábrica por método
  • context_payment.tsContexto que guarda a estratégia e delega
  • rail_settlement.tsTrilhos HTTP que recebem o plano, e o cliente que os chama

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
  4. bun run test:mutation# mutação com Stryker
Requisitos
Bun

Relações

Onde ele se encaixa

Mapa
  1. Strategy Pattern
  • Combina com4
  • Alternativa a2

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Strategy Pattern?

Próximo projeto · Padrões de Design de ServiçoChain of Responsibility
Esc

↑ ↓ navegarEnter abrir191 resultados