Blog Acensi
L'inversion de dépendance

L’inversion de dépendance

Dernier pilier des pratiques SOLID, l’inversion de dépendance est un gage de modularité, de simplification de maintenance et facilite tant la conception, que la réalisation. En revanche, il faut être prêt à saturer son code d’interface, et accepter de perdre de vue l’implémentation de ce que l’on ne développe pas. Explications de ce principe de confiance encadré par des contrats :
« Un composant de haut niveau ne doit pas dépendre de composants de bas niveau » et comme par nature les composants de bas niveau ne peuvent pas dépendre de composants de haut niveau, le couplage entre composants s’affaiblit.
Et comme un schéma est souvent plus explicite, voici une situation classique ne respectant pas l’inversion de dépendance :
inversion dépendance
Nous avons ici de la duplication de fonctionnalité, ainsi qu’une dépendance forte entre par exemple le métier et un mécanisme de log.
Pour obtenir l’inversion, nous allons passer par des contrats d’interface, à partir de ce moment, les composants ne dépendent plus de l’implémentation, mais uniquement de leur contrat d’interface.
Voici le résultat :
inversion dépendance2

Le résultat est une disparition de la dépendance, permettant de remplacer et maintenir facilement chaque composant. Au passage, la duplication de fonctionnalités disparaît presque par magie.
A noter, un composant déjà écrit ne répond pas nécessairement au contrat d’interface que l’on souhaite (d’ailleurs en général, ce ne sera pas le cas). Dans ce cas, le design pattern « adapter » résout la situation avec simplicité. On insère donc une classe répondant à l’interface souhaitée et convertissant les appels dans l’interface à laquelle répond le composant « rebelle ».

Reste le problème de savoir comment fournir les interfaces aux composants les utilisant.
Plusieurs méthodes sont possibles, via les patterns « factory » ou « service locator » par exemple.
En dehors de la méthode concrète utilisée, le point vraiment important est le « point de composition unique ». C’est-à-dire que l’endroit où est indiqué quelle classe concrète réalise l’implémentation de chaque interface, soit unique dans l’application. Ce peut être un fichier de config ou une partie du code, mais toutes les interfaces utilisées et leurs implémentations doivent êtres décrites au même endroit.

Ajouter un commentaire

Pourquoi ce blog ?

Pour permettre à nos consultants et experts techniques de partager leurs connaissances et retours d’expérience autour des sujets qui les passionnent. Ce blog, intégralement écrit par eux, a pour vocation d’être un véritable lieu d’échanges et d’apprentissage.

Alors n’hésitez pas à commenter nos articles pour rejoindre la conversation !

Une suggestion ?

Si vous avez des idées pour améliorer ce blog, nous sommes à l’écoute de vos remarques. Vous pouvez nous écrire via le formulaire de contact qui se trouve en bas de page.

Bonne visite !