Principes S.O.L.I.D - Dependency inversion principle (DIP)

1. Problème initial

Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :



Cela paraît naturel au premier abord mais pose en réalité deux problèmes essentiels :
  • Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
  • Il n'est pas possible de réutiliser les modules de haut niveau indépendamment de ceux de bas niveau. En d'autres termes, il n'est pas possible de réutiliser la logique d'une application en dehors du contexte technique dans lequel elle a été développée.
Selon le principe d’inversion des dépendances, la relation de dépendance doit être inversée : les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau.



2. Solution associée

La meilleure solution semble être l’abstraction.

Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous :



Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :



Dans ce nouveau schéma B dépend désormais du couple (A,I), la dépendance est donc inversée. Le couple (A,I) forme une sorte d'extension de la classe A dans laquelle on inclut une représentation abstraite des dépendances de A.

Remarque : On reconnaît ici le mécanisme de "délégation abstraite" présenté dans le Principe d'Ouverture/Fermeture. L'ouverture/fermeture est en effet obtenue en inversant la dépendance entre A et B, de sorte que A n'est plus impactée par des changements de B.