Como a Inversão de controle está relacionada à Inversão de dependência

Em muitos artigos em toda a web, os termos Princípio de Inversão de Controle e Inversão de Dependência parecem misturados e usados como sinônimos (mais confusão é imposta pelas ferramentas chamadas "DI-Containers" e "IoC-Containers"). Um artigo da Wikipedia faz um bom trabalho tentando explicar que IoC não é o mesmo que DI:

inversão de controle (IoC) descreve um design no qual partes escritas sob encomenda de um programa de computador recebem o fluxo de controle de uma biblioteca genérica e reutilizável

Portanto, o DIP é sobre ter seus módulos dependentes de abstrações, em vez de implementações concretas.

E a IoC trata de dar controle sobre o fluxo do programa a um módulo separado. E uma das coisas que você pode fazer com que este módulo faça é resolver as dependências no tempo de execução.

Essa diferença parece justa, mas nunca vi alguém mencionar outras aplicações do princípio da IoC além da resolução de dependência. A definição da Wikipedia é bastante ampla e parece que você poderia fazer muito mais com um módulo que pode fazer chamadas para seu código personalizado com base em sua configuração e em alguma lógica interna.

Então, aqui estão algumas perguntas que ainda não consigo entender:

Qual é a relação real entre IoC e DIP? A IoC sempre serve como meio de implementar o DIP?
Por que as ferramentas para resolução de dependência são chamadas de contêineres DI e IoC? Isso implica que DI e IoC são a mesma coisa.

Nota : Esta pergunta não é uma duplicata de Qual é a diferença entre DI e IoC , porque a última pergunta sobre Injeção de Dependência, não Inversão de Dependência.

design-patterns inversion-of-control dependency-inversion

— Andre Borges
fonte

Possível duplicata de Qual é a diferença entre DI e IoC?

— mosquito

@gnat, não, não é, por favor, veja minha edição

— Andre Borges

concordo, eu perdi essa pena #

— 396

IMO, a resposta simples é "eles são os mesmos". IoC é outro nome para inversão de dependência e ambos são uma maneira de obter injeção de dependência. Eu vejo "inversão de dependência" como um termo profundamente inútil, pois é facilmente confundido com injeção. Portanto, há DI (injeção) e IoC é uma maneira de obter inversão de dependências / controle via injeção.

— David Arno

Há um ótimo artigo no site de Martin Fowler que contém um capítulo específico sobre a diferença entre DIP, DI e IoC . A essência (copiada desse site) é

O DI é sobre como um objeto adquire uma dependência. Quando uma dependência é fornecida externamente, o sistema está usando o DI. IoC é sobre quem inicia a chamada. Se o seu código inicia uma chamada, não é IoC, se o contêiner / sistema / biblioteca chama novamente no código que você forneceu, é IoC.

DIP, por outro lado, é sobre o nível da abstração nas mensagens enviadas do seu código para a coisa que ele está chamando. Certamente, o uso de DI ou IoC com DIP tende a ser mais expressivo, poderoso e alinhado a domínios, mas são sobre diferentes dimensões ou forças em um problema geral. DI é sobre fiação, IoC é sobre direção e DIP é sobre forma.

— JDT
fonte

IoC é sobre quem inicia a chamada - quem a chama para quê? Se eu escrevo, ISomeInterface object = container.Resolve<ISomeInterface>()isso é IoC ou não?

— Andre Borges

O que você escreve é uma implementação no padrão localizador de serviço. Isso também é IoC. Não IoC é ISomeInterface object = new MyClass (). Portanto, a chamada que se pretende é a "chamada à instanciação" (ou quem chama de 'novo').

— precisa saber é o seguinte

"DIP, por outro lado, é sobre o nível da abstração nas mensagens enviadas do seu código para a coisa que ele está chamando." Isso soa como um absurdo para mim. Onde está a inversão nisso? Ele está descrevendo abstração de dependência, não inversão.

— 21416 David Arno #

@DavidArno, você está dizendo que não podemos confiar no site de Martin Fowler?

— Holdenmcgrohen 03/03

@holdenmcgrohen, são as opiniões dele sobre as coisas. Só porque é Martin Fowler, não é verdade. Às vezes, ele está errado na IMO, por exemplo, com relação ao "modelo de dados de anemia". Outras vezes, é muito perspicaz. Nesta ocasião, acho que ele também está errado, pois não faz sentido.

— David Arno