Pular para o conteúdo
thiagoetipadrões

Contatos

apps/patterns/dependency-injection

011 · Padrões Fundamentais · ≈ 5 min de estudo

Dependency Injection

A classe recebe as dependências pelo construtor em vez de criá-las com new, e depende de interfaces, não de implementações. Um container IoC, configurado só no ponto de entrada, registra e resolve os serviços e controla o ciclo de vida. Use quando uma implementação precisa ser trocada — banco real no demo, dublê no teste — sem tocar no serviço.

passos
6
arquivos
8
testes
2
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Uma plataforma de pagamentos processa pagamentos com um serviço que só conhece duas interfaces: validar o valor e guardar o pagamento. No demo, o container injeta o repositório real contra PostgreSQL; no teste, um repositório de registro — o serviço não muda uma linha.

Planta

Fluxo
7/7
demo.ts: configura o containerContainerIocServicePaymentInterfacePaymentValidatorInterfacePaymentRepositoryValidatorPaymentLimitRepositoryPaymentPostgrespg.Pool: PostgreSQLregister evalidate no bootresolve e injetapelo construtordepende dedepende deimplementaimplementagrava e lê
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Recebe dependências prontas, não as cria.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

resolve+1
pg.Pool+1
new+1
  1. 01

    Registroregister(name, factory, lifetime) no ponto de entrada; o tipo Registry liga cada nome ao que ele resolve

  2. 02

    Resolução preguiçosaA factory só roda no resolve, e resolve as próprias dependências do container

  3. 03

    Ciclo de vidaSingleton é construído uma vez (o pg.Pool compartilhado); transient, a cada resolve

  4. 04

    Constructor injectionServicePayment(validator, repository) recebe interfaces — nenhuma chamada new a colaborador dentro dele

  5. 05

    Falha cedovalidate() resolve todos os singletons no boot; nome não registrado e dependência circular viram erro com o nome

  6. 06

    Troca de implementaçãoUm novo register com o mesmo nome substitui o anterior

apps/patterns/dependency-injection

8 arquivos

sql/

  • 01_schema.sqlschemaTabela payments

src/

  • container_ioc.tsContainer tipado: registro, resolução, ciclo de vida, circularidade, validação no boot
  • service_payment.tsInterfaces, validador, repositório PostgreSQL e ServicePayment
  • config_payment.tsLê e valida o ambiente no boot
  • container_ioc.test.tstesteCiclo de vida, falhas do container, troca de implementação, fronteira do limite
  • service_payment.test.tstesteRepositório real contra PostgreSQL
  • demo.tsdemoConfigura o container e processa pagamentos

./

  • docker.shinfraSobe o PostgreSQL com o schema

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário

Testes: bun run test.

Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. Dependency Injection
  • Combina com3
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Dependency Injection?

Próximo projeto · Padrões FundamentaisDistributed Tracing
Esc

↑ ↓ navegarEnter abrir191 resultados