Principe d'inversion de dépendance (DIP)

Le cinquième principe de SOLID est le principe d'inversion de dépendance , abrégé en DIP .

Ce principe stipule que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient dépendre de l'abstraction.

Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

Voyons ce que dit ce principe et ce qu'est la dépendance !

La classe A dépend de la classe B pour effectuer ses opérations, donc la classe A est une classe de haut niveau et B est une classe de bas niveau.

Qu'est-ce que l'Abstraction ?

Animal et Food sont des exemples de concepts abstraits, ce qui signifie qu'ils sont des modèles mentaux qui n'existent pas dans le monde réel et ne sont pas implémentables. Dans le monde réel, nous observons des types spécifiques d'animaux, tels que des chiens, et des types spécifiques de nourriture, tels que des spaghettis, etc. Cela signifie que nous ne pouvons pas implémenter des concepts abstraits tels que "aliments" et "animaux", mais les chiens et les spaghettis existent et sont implémentables.

Les interfaces et les classes abstraites sont des outils pour les concepts abstraits.

Pourquoi avons-nous besoin du principe d'inversion de dépendance?

DIP vous aide à faire en sorte que votre code soit couplé plutôt que étroitement couplé

• Couplage lâche : lorsqu'un objet obtient l'objet à utiliser à partir de sources externes, nous l'appelons couplage lâche. En d'autres termes, le couplage lâche signifie que les objets sont indépendants.
• Couplage étroit : Lorsqu'un groupe de classes est fortement dépendant l'une de l'autre, on parle alors de couplage étroit.

Supposons que vous travaillez sur un projet logiciel avec une équipe composée de développeurs Front-end et Back-end.

Et le projet nécessite à la fois un front-end et un back-end pour la mise en œuvre.

La classe de haut niveau, qui est le projet, dépend des classes de niveau inférieur de FrontEndDeveloper et BackEndDeveloper afin de continuer son travail. Et si nous voulons apporter une modification aux classes de niveau inférieur, cela peut affecter directement le projet qui les utilise.

Par exemple, si une méthode est ajoutée à la classe BackEndDeveloper ou si Python est utilisé à la place de Java, nous devons finalement appliquer également ces modifications à la classe Project.

De plus, les classes de haut niveau ne sont pas réutilisables, ce qui signifie que si nous ajoutons du nouveau personnel dans d'autres domaines à notre équipe, comme MobileDeveloper, nous devons changer la classe Project ou créer une classe distincte pour chaque champ, ce qui enfreint la cinquième principe de SOLIDE.

Eh bien, quelle est la solution ?

Créons une interface pour tous les développeurs qui a une méthode "développer", et chaque programmeur implémente cette méthode en fonction de son propre domaine de travail.

Maintenant, notre classe Project peut recevoir une liste de développeurs et appeler leur méthode "develop" sans aucune dépendance.

En faisant cela, nous avons suivi le principe DIP

De cette façon, peu importe si le programmeur est un développeur backend, frontend ou mobile, et notre classe Project ne dépend d'aucune des classes de niveau inférieur ou de leurs méthodes.