Como a injeção de dependência não está apenas movendo a complexidade para uma classe separada?

Estive estudando o uso da estrutura Typhoon para injeção de dependência nesta semana. Entendo que a separação da construção de objetos é benéfica para a substituição de componentes arbitrários por simulações durante o teste de unidade, e até agora já vi benefícios apenas com isso.

Mas não posso deixar de pensar que, onde antes eu tinha uma classe de controlador de exibição enorme que tinha dezenas de importações de cabeçalho, agora tenho uma classe de fábrica enorme que tem dezenas de importações de cabeçalho. Devo evitar ter uma aula massiva de fábrica?

dependency-injection

— Vencedor
fonte

Em uma década, espero que o DI assuma a lista contundente de Singleton, mas desta vez por boas razões. Ele tem alguns usos bons, mas sugiro ter muito cuidado em avaliar o impacto.

— quer

Não acho que a injeção de dependência seja uma maneira de reduzir a complexidade, mas uma maneira de evitar dependências implícitas (uso de símbolos globais / variáveis livres) em favor de dependências explícitas (use parâmetros explícitos / variáveis vinculadas). Portanto, a complexidade ainda existe, mas você é forçado a lidar com ela porque a torna explícita nas assinaturas de método / construtor.

— Giorgio

Observe que praticamente qualquer sistema de organização de código pode ser descrito como "apenas movendo a complexidade para outro lugar". Não se trata tanto de remover a complexidade, mas de organizá-la da maneira mais lógica e útil.

Se você precisar importar 50 cabeçalhos, precisará fazê-lo em algum lugar. O DI ajuda você com a maneira mais fácil de testar seu código de unidade.

— BЈовић

Então, você está dizendo que agora seu controlador está focado no controle e sua fábrica de importação de cabeçalho está focada nas importações de cabeçalho? Como isso pode ser ruim, esteja você usando uma estrutura de DI ou não?

— PDR

Respostas:

A Injeção de Dependência simplesmente ajuda a definir como um objeto sabe sobre outro objeto dependente. Isso não ajudará a reduzir a complexidade geral do sistema. Se você precisou de dezenas de importações antes do DI, ainda precisará de dezenas de importações depois. A diferença é que essas importações estarão em um local (classe) que faz mais sentido (fábrica, construtor, etc.).

Ao permitir que as dependências sejam fornecidas por meio de um construtor ou método, você permite a flexibilidade de fornecer um objeto dependente diferente, mas ainda válido, para sua classe e aumenta a coesão dessa classe, removendo preocupações.

Existem vários princípios que são semelhantes e geralmente são usados juntos: Injeção de Dependência (DI), Inversão de Controle (IoC) e Princípio de Inversão de Dependência (DIP)

Deste artigo http://martinfowler.com/articles/dipInTheWild.html

DI é sobre fiação, IoC é sobre direção e DIP é sobre forma

— Seth M.
fonte

+1, para a última cotação. É o melhor esclarecimento desses três conceitos que as pessoas geralmente não entendem.

— haylem

O artigo acima é realmente excelente. Uma explicação suficientemente profunda e muito clara.

— DemetriKots 12/09

A injeção de dependência não reduz a complexidade, mas aumenta a capacidade de manutenção através da separação de preocupações e redução do acoplamento.

Mas não posso deixar de pensar que, onde antes eu tinha uma classe de controlador de exibição enorme que tinha dezenas de importações de cabeçalho, agora tenho uma classe de fábrica enorme que tem dezenas de importações de cabeçalho. Devo evitar ter uma aula massiva de fábrica?

Você deveria evitar aulas "enormes", ponto final. Então, digamos que você divida o controlador de exibição em classes menores e mais sustentáveis. Agora todos eles são responsáveis por se apossar de suas dependências. O DI ajuda a mover esse gerenciamento de dependências de todas essas classes para uma classe de fábrica / configuração que é responsável apenas pelo gerenciamento de dependências - consulte Princípio de responsabilidade única. E, embora certamente seja muito menos "hediondo" do que o controlador de exibição original, se ele for muito grande, você sempre terá a opção de dividi-lo em classes de gerenciamento de dependência menores, responsáveis por diferentes partes do aplicativo.

— Michael Borgwardt
fonte

Nas palavras dos leigos:

A injeção de dependência move a complexidade para onde causa menos danos.

EDIT para @gnat: DI não está apenas movendo a complexidade para uma classe separada, está movendo-a para onde causa menos danos.

— Tulains Córdova
fonte

Como isso responde à pergunta?

— mosquito

O @gnat adicionou uma edição, minha resposta explica em minha opinião como o DI não está apenas movendo a complexidade para uma classe separada.

— Tulains Córdova