Quel est le lien entre l'inversion de contrôle et l'inversion de dépendance

Dans de nombreux articles sur le Web, les termes Inversion de contrôle et Principe d'inversion de dépendance semblent être mélangés et utilisés comme synonymes (une confusion supplémentaire est renforcée par les outils appelés "DI-Containers" et "IoC-Containers"). Un article de Wikipedia fait un bon travail en essayant d'expliquer que l'IoC n'est pas la même chose que la DI:

l'inversion de contrôle (IoC) décrit une conception dans laquelle des parties personnalisées d'un programme informatique reçoivent le flux de contrôle d'une bibliothèque générique et réutilisable

Ainsi, DIP consiste à faire dépendre vos modules des abstractions plutôt que des implémentations concrètes.

Et l'IoC consiste à donner le contrôle de votre flux de programme à un module distinct. Et l'une des choses que vous pouvez faire pour ce module est de résoudre les dépendances au moment de l'exécution.

Cette différence semble juste, mais je n'ai jamais vu personne mentionner d'autres applications du principe IoC autres que la résolution des dépendances. La définition de Wikipédia est assez large, et il semble que vous pourriez faire beaucoup plus avec un module qui peut effectuer des appels dans votre code personnalisé en fonction de sa configuration et d'une logique interne.

Voici donc quelques questions que je n'arrive pas encore à comprendre:

Quelle est la relation réelle entre l'IoC et le DIP? L'IoC sert-il toujours de moyen de mise en œuvre du DIP?
Pourquoi les outils de résolution des dépendances sont-ils appelés conteneurs DI et IoC? Cela implique que DI et IoC sont la même chose.

Remarque : Cette question n'est pas un doublon de Quelle est la différence entre DI et IoC , car ce dernier pose des questions sur l'injection de dépendance, pas sur l'inversion de dépendance.

design-patterns inversion-of-control dependency-inversion

— Andre Borges
source

Duplication possible de Quelle est la différence entre DI et IoC?

— moucher

@gnat, non ce n'est pas le cas, veuillez consulter mon montage

— Andre Borges

d'accord, j'ai raté ça désolé

— moucher

OMI, la réponse simple est "ce sont les mêmes". IoC est un autre nom pour l'inversion de dépendance et les deux sont un moyen de réaliser l'injection de dépendance. Je vois «l'inversion de dépendance» comme un terme profondément inutile car il est trop facilement confondu avec l'injection. Il y a donc DI (injection) et IoC est un moyen de réaliser l'inversion des dépendances / contrôle via l'injection.

— David Arno

Il y a un excellent article sur le site de Martin Fowler qui contient un chapitre spécifiquement sur la différence entre DIP, DI et IoC . L'essentiel de celui-ci (tel que copié à partir de ce site) est

DI concerne la façon dont un objet acquiert une dépendance. Lorsqu'une dépendance est fournie en externe, le système utilise DI. L'IoC concerne qui initie l'appel. Si votre code initie un appel, ce n'est pas l'IoC, si le conteneur / système / bibliothèque rappelle le code que vous lui avez fourni, est-ce l'IoC.

DIP, d'autre part, concerne le niveau d'abstraction dans les messages envoyés de votre code à la chose qu'il appelle. Certes, l'utilisation de DI ou IoC avec DIP a tendance à être plus expressive, puissante et alignée sur le domaine, mais elles concernent des dimensions ou des forces différentes dans un problème global. DI concerne le câblage, l'IoC concerne la direction et le DIP concerne la forme.

— JDT
source

L'IoC est de savoir qui initie l'appel - qui lance l'appel à quoi? Si j'écris, ISomeInterface object = container.Resolve<ISomeInterface>()c'est IoC ou pas?

— Andre Borges

Ce que vous écrivez est une implémentation dans le modèle de localisateur de services. C'est aussi IoC. Pas IoC n'est un objet ISomeInterface = new MyClass (). Ainsi, l'appel qui est destiné est «l'appel à l'instanciation» (ou qui appelle «nouveau»).

— Sjoerd222888

"DIP, d'autre part, concerne le niveau d'abstraction dans les messages envoyés de votre code à la chose qu'il appelle." Cela me semble absurde. Où est l'inversion là-dedans? Il décrit l'abstraction des dépendances, pas l'inversion.

— David Arno

@DavidArno, dites-vous que nous ne pouvons pas faire confiance au site Web de Martin Fowler?

— holdenmcgrohen

@holdenmcgrohen, ce sont ses opinions sur les choses. Ce n'est pas parce que c'est Martin Fowler que cela se fait. Il se trompe parfois à l'OMI, par exemple en ce qui concerne le "modèle de données sur l'anémie". D'autres fois, son très perspicace. A cette occasion, je pense qu'il a tort aussi car cela n'a pas de sens.

— David Arno