Quel est le principe d’Inversion de dépendance et pourquoi est-elle importante ?

Question

Quel est le principe d’Inversion de dépendance et pourquoi est-elle importante ?

Answer 1

Les livres de Développement Agile de Logiciels, Principes, Modèles et Pratiques Agile et Principes, Modèles et Pratiques en C# sont les meilleures ressources pour comprendre pleinement les objectifs et les motivations derrière le Principe d'Inversion des Dépendances. L'article "L'Inversion de la Dépendance Principe" est aussi une bonne ressource, mais en raison du fait que c'est une version condensée d'un projet qui a finalement fait son chemin dans le mentionné précédemment livres, il laisse de côté certains des discussions importantes sur le concept de package et de l'interface de la propriété qui sont essentiels pour distinguer ce principe à partir du plus général de conseiller de "programme pour une interface, pas une mise en œuvre" trouvé dans le livre Design Patterns (Gamma, et. al).

Afin de fournir un résumé, l'Inversion de Dépendance Principe est principalement à propos de l'inversion de la classique direction de dépendances de "niveau supérieur" composants "de niveau inférieur" composants tels que "niveau inférieur" composants sont tributaires des interfaces détenue par le "niveau supérieur". (Note: le "niveau supérieur" de la composante désigne ici le composant nécessitant des dépendances externes/services, pas nécessairement de sa conception de la position au sein d'une architecture en couches.) En agissant de la sorte, le couplage n'est pas réduit , de sorte qu'il est décalé à partir de composants qui sont théoriquement moins précieux pour la réutilisation de composants qui sont théoriquement plus précieux pour la réutilisation.

Ceci est réalisé par la conception de composants dont les dépendances externes sont exprimés dans les termes d'une interface pour laquelle une mise en œuvre doivent être fournis par le consommateur de la composante. En d'autres termes, la définition des interfaces exprimer ce qui est requis par le composant, pas la façon dont vous utilisez le composant (par exemple, "INeedSomething", pas "IDoSomething").

Ce que l'Inversion de Dépendance Principe ne fait pas référence à l'est de la simple pratique de l'abstraction de dépendances grâce à l'utilisation d'interfaces (par exemple, MyService → [ILogger ⇐ Enregistreur]). Tout ce découple un composant de la mise en œuvre spécifique de détail de la dépendance, il n'a pas d'inverser la relation entre la consommation et de la dépendance (par exemple, [MyService → IMyServiceLogger] ⇐ Enregistreur.

L'importance de l'Inversion de Dépendance Principe est principalement vu dans le développement de la réutilisation des composants logiciels qui s'appuient sur des dépendances externes (enregistrement, validation, etc.) depuis la prise de dépendances sur ces dépendances exige les consommateurs à exiger les mêmes dépendances. Cela peut être problématique lorsque les consommateurs de votre bibliothèque choisissez d'utiliser une autre bibliothèque pour les mêmes besoins d'infrastructure (par exemple, NLog vs log4net), ou s'ils choisissent d'utiliser une version plus récente de la bibliothèque requise, ce qui n'est pas compatible avec la version requise par votre bibliothèque.

Une plus longue discussion de ce principe, car elle se rapporte à la simple utilisation des interfaces, de l'Injection de Dépendance, et la séparation de l'Interface de modèle peut être trouvé ici.

Answer 2

Vérifiez ce document: Le Principe d'Inversion des Dépendances.

Il dit en gros:

• Haut niveau les modules ne devrait pas dépendre de bas niveau des modules. Les deux doit dépendre des abstractions.
• Les Abstractions ne doit jamais dépendre de détails. Les détails dépendent des abstractions.

Comme quoi il est important, en bref: les changements sont risqués, et en fonction d'un concept, plutôt sur la mise en oeuvre, vous réduire le besoin de changement lors de l'appel de sites.

Effectivement, le DIP réduit le couplage entre les différents morceaux de code. L'idée est que, bien qu'il existe de nombreuses façons de mettre en œuvre, par exemple, une fonction de journalisation, la façon dont vous l'utiliser il faut être relativement stable dans le temps. Si vous pouvez extraire une interface qui représente le concept de l'exploitation forestière, cette interface devrait être beaucoup plus stable dans le temps que sa mise en œuvre, et les sites d'appel devrait être beaucoup moins affectées par les changements que vous pouvez faire tout en maintenant ou en extension que le mécanisme de journalisation.

Par aussi de faire de la mise en œuvre dépend d'une interface, vous obtenez la possibilité de choisir au moment de l'exécution de mise en œuvre qui est le mieux adapté pour votre environnement particulier. Selon les cas, cela peut être intéressant aussi.

Answer 3

Pour moi, le Principe d'Inversion des Dépendances, comme décrit dans l' officielles de l'article, c'est vraiment un piètre tentative d'augmenter la réutilisabilité des modules qui sont intrinsèquement moins réutilisables, ainsi que d'un moyen pour contourner un problème dans le langage C++.

Le problème en C++ est que les fichiers d'en-tête contiennent généralement des déclarations de champs privés et des méthodes. Par conséquent, si un haut niveau en C++ module inclut le fichier d'en-tête pour un faible niveau module, cela dépendra de la réelle mise en œuvre des détails de ce module. Et qui, évidemment, n'est pas une bonne chose. Mais ce n'est pas un problème dans le plus moderne des langues couramment utilisées aujourd'hui.

De haut niveau, les modules sont intrinsèquement moins réutilisables que le faible niveau des modules, parce que les anciens sont normalement plus de l'application/le contexte spécifique de ce dernier. Par exemple, un composant qui implémente une INTERFACE utilisateur de l'écran est de haut niveau et également très (complètement?) spécifique à l'application. Tenter de réutiliser un tel composant dans une application différente, est contre-productif, et ne peut que conduire à plus de génie.

Ainsi, la création d'une catégorie distincte de l'abstraction au même niveau d'un composant qui dépend d'un composant B (qui ne dépend pas de A) peut être effectuée que si le composant A va vraiment être utile pour les réutiliser dans différentes applications ou des contextes. Si ce n'est pas le cas, alors l'application de DIP serait une mauvaise conception.

Answer 4

Les bonnes réponses et les bons exemples sont déjà données par d'autres ici.

La raison DIP est important car il assure le OO-principe "lousely couplé design".

Les objets dans votre logiciel ne devrait PAS entrer dans une hiérarchie où certains objets sont le haut-niveau, dépend des objets de bas niveau. Les changements dans les objets de bas niveau sera alors d'ondulation sur vos objets de plus haut niveau qui rend le logiciel très fragile pour le changement.

Vous voulez que votre "top-niveau" des objets pour être très stable et pas fragile pour le changement, par conséquent, vous devez inverser les dépendances.

Answer 5

Inversion de contrôle conteneurs et le modèle d’Injection de dépendance par Martin Fowler est un bon lire aussi. J’ai trouvé Tête première Design Patterns un livre génial pour ma première incursion dans DI et autres modes d’apprentissage.