Pular para o conteúdo
thiagoetipadrões

Contatos

apps/service-design/bridge-pattern

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

Bridge

Separa duas dimensões que variam de forma independente — o que se diz e por onde se diz — em duas hierarquias ligadas por composição. Com herança seriam N × M subclasses; com a ponte são N + M classes, combinadas em tempo de execução. Use quando duas variações reais se cruzam, como tipo de notificação × canal ou relatório × formato.

passos
6
arquivos
3
testes
0
tecnologias
3
Lógica puraTypeScriptBunStryker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Banco digital confirma cada pagamento (PIX, TED, boleto) ao cliente. Há dois tipos de aviso — simples e detalhado, com comprovante — e três canais — SMS, e-mail e push. Cada canal tem o próprio limite de tamanho; nenhum tipo de aviso precisa saber disso.

Planta

Fluxo
6/6
Abstracao: o que dizerImplementacao: por ondeAbstractPaymentNotifierNotifierPaymentSimpleNotifierPaymentDetailedInterfaceNotificationChannelChannelNotificationSmscorta em 160ChannelNotificationEmailChannelNotificationPushcorta em 100compoe, nunca herdaimplementaimplementaimplementa
6

6 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Abstração e implementação evoluem separadas.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    InterfaceNotificationChannel é o lado da implementação: um único método deliver(recipient, subject, body), sem detalhe de canal nenhum

  2. 02

    AbstractPaymentNotifier recebe o canal no construtor e delega a ele — a ponte é essa referência

  3. 03

    NotifierPaymentSimple e NotifierPaymentDetailed decidem o texto (valor em centavos formatado em reais, id, liquidação, comprovante)

  4. 04

    Cada canal aplica a própria regraSMS corta no segmento de 160 caracteres, push no corpo de 100, e-mail envia inteiro

  5. 05

    Qualquer aviso funciona com qualquer canalnew NotifierPaymentDetailed(new ChannelNotificationSms())

  6. 06

    Canal novo é uma classe, sem tocar nos avisos; aviso novo é uma classe, sem tocar nos canais

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • N + M classes em vez de N × M

  • Troca de canal em tempo de execução

  • Canal e aviso evoluem sem se tocar

  • Limite de cada canal num lugar só

Custos

  • Duas hierarquias e uma indireção a mais

  • Interface do canal precisa ficar genérica para servir a todos

  • Excesso quando só uma dimensão varia — aí é Strategy

  • Detalhe de canal na interface faz a ponte vazar

apps/service-design/bridge-pattern

3 arquivos

src/

  • notifier_payment.tsAbstração: o aviso de pagamento e suas variantes
  • channel_notification.tsImplementação: os canais e seus limites
  • demo.tsdemoAs 6 combinações a partir de 5 classes

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. Bridge Pattern
  • Combina com2
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Bridge Pattern?

Próximo projeto · Padrões de Design de ServiçoSpecial Case (Null Object)
Esc

↑ ↓ navegarEnter abrir191 resultados