Exemplo De Um Conceito

Por que quase todo mundo implementa injeção de dependência errado

Você já deve ter visto aquele padrão em que um container gigante é injetado em todos os lugares. Não é injeção de dependência, é injeção de preguiça. Eu li uma thread no HN há um tempo onde alguém mostrava seu código com mais de 40 parâmetros no construtor e se perguntava por que as coisas não escalavam. A resposta era óbvia pra quem já tinha passado por isso, mas ninguém fala abertamente que isso é comum. Injeção de dependência significa separar a criação dos objetos do uso deles. Em vez de um classe instanciar suas próprias dependências com new, elas são fornecidas de fora. Isso soa simples demais porque é simples no papel. O problema é que a simplicidade desaparece quando você tenta aplicar num sistema existente que foi construído sem pensar nisso desde o início. Pra quem tá começando, aqui vai um exemplo bem direto. Suponha que você tenha uma classe OrderService que precisa de um repository pra salvar pedidos. A versão errada seria:

sem injeção: class OrderService {
  constructor() {
    this.repo = new OrderRepository();
  }
} A versão com injeção seria:

com injeção: class OrderService {
  constructor(repo) {
    this.repo = repo;
  }
} Pronto. Fim da explicação teórica. Agora vem a parte que ninguém conta nos tutoriais bonitos.

Quando eu trabalhei num projeto de e-commerce internamente, tentamos refatorar toda a camada de serviços pra usar injeção de dependência com um container do tipo InversifyJS. O resultado foi um pesadelo de configuração que levou três semanas pra funcionar. O problema principal era que tínhamos dependências circulares — não era óbvio à primeira vista porque várias classes precisavam umas das outras de forma indireta, tipo OrderService precisando de UserService que precisava de OrderService. O container simplesmente travava. O workaround que funcionou foi parar de usar anotações automáticas e fazer o binding manual de cada dependência num arquivo separado, mapeando explicitamente cada interface pro seu implementador. Foi mais código, mas era previsível. Também eliminamos as dependências circulares reestruturando duas classes que estavam fazendo algo que deveria ser responsabilidade de uma terceira. Levou dois dias. Uma coisa contra-intuitiva sobre injeção de dependência é que ela não resolve problemas de design. Muitos desenvolvedores pensam que adicionar um container de DI vai transformar código espaguete em algo limpo. Não vai. Se o seu domínio tá mal modelado, a injeção só vai deixar o código feio de um jeito mais estruturado. O benefício real aparece quando você já tem boas responsabilidades separadas e quer testes mais fáceis, porque aí conseguir mockar dependências é trivial.

Outro detalhe prático que gera dor de cabeça é o lifetime management. Scoped, singleton, transient — cada um desses modos tem implicações sérias em aplicação web. Eu já vi um sistema onde um serviço scoped continha cache interno e era resolvido como singleton por engano. O cache crescia sem limites até dar out of memory em produção. Levou seis horas pra identificar porque o stack trace apontava pra outro lugar completamente. Se o seu projeto é pequeno, tipo uma API REST simples com menos de meia dúzia de endpoints, container de DI é overkill. Injeção manual via construtor resolve e é mais transparente. O custo de manutenção do container começa a compensar apenas quando o número de dependências cruzadas ultrapassa algo em torno de quinze classes com relacionamentos não triviais entre si. O ponto é: injeção de dependência é uma ferramenta útil, não uma solução mágica. A prática correta envolve entender o ciclo de vida dos objetos no seu contexto específico e aceitar que refactorings iniciais vão Doer um pouco antes de melhorar.