Principe d'inversion de la dépendance: comment définir la «politique de haut niveau» et les «détails de bas niveau» pour d'autres personnes?

J'essaie d'expliquer le principe d'inversion de dépendance à mes collègues (pour la plupart juniors). Comment définir laquelle est la «politique de haut niveau» et laquelle est le «détail de bas niveau» dans un logiciel? Par exemple, si notre logiciel automatise le flux de travail de plusieurs applications métier, pourquoi disons-nous que l'automatisation du flux de travail est la politique de haut niveau et que les applications métier sont les détails?

Remarque: cela a été complètement réécrit à partir de mon exemple précédent

Pensez aux prises de courant. Dans un pays donné, la politique de haut niveau est que les prises de courant sont toujours les mêmes. Peu importe d'où vous vous approvisionnez en électricité (charbon, gaz, nucléaire), les prises sur le mur doivent toujours fournir la même quantité d'énergie, via le même ensemble de connecteurs.

Vous pouvez maintenant brancher n'importe quel appareil sur cette prise, car ils ont tous une interface commune, la "prise". La politique de haut niveau n'a jamais à dicter une partie de ce détail de mise en œuvre. Branchez simplement quelque chose et c'est parti.

Maintenant, si vous avez un appareil qui ne veut pas d'alimentation CA - peut-être qu'il fonctionne sur un circuit 7 V CC - vous pouvez toujours utiliser cette politique de haut niveau, vous avez juste besoin d'une sorte d'adaptateur entre l'alimentation et l'appareil. Et, comme tout le monde a la même politique de haut niveau, le fabricant peut l'intégrer dans l'implémentation, sans aucune modification de la politique de haut niveau. La personne qui connecte l'implémentation à la stratégie (vous, brancher votre ordinateur portable) n'a pas vraiment besoin de comprendre non plus.

De plus, si le fabricant souhaite vendre le même appareil dans un autre pays, il lui suffit de développer un adaptateur différent. Ainsi, la même implémentation peut fonctionner avec plusieurs stratégies tandis que la même stratégie peut exécuter plusieurs implémentations.

Ceci est un parfait exemple d'inversion de dépendance.

Mais voici la partie intéressante: revenez à ce que j'ai dit en premier. "Peu importe d'où vous vous approvisionnez en électricité." Il s'agit également d'un détail d'implémentation. La politique de haut niveau est toujours que toutes les prises de courant ont la même forme et émettent le même type d'alimentation. Les détails de mise en œuvre de bas niveau sont à la fois d'où vient l'électricité et ce qu'elle fonctionne.

En termes de programmation, cela signifie que la politique de haut niveau est l'interface (lorsqu'un langage le prend en charge. Une autre forme de DI est le typage de canard.) Qu'une API fournit et que l'application consomme, et les détails d'implémentation de bas niveau sont à la fois les l’application qui la consomme et l’API elle-même, qui ne doivent pas se comprendre.

Des adaptateurs peuvent être utilisés pour adapter la même implémentation à différentes politiques.

L'approche classique de la réutilisation de logiciels consiste à créer des composants qui ne dépendent de rien d'autre (c'est ce qui les rend de bas niveau), puis à construire des composants de niveau supérieur qui dépendent de composants de niveau inférieur. "haut niveau" et "bas niveau" sont déterminés spécifiquement par la direction de la dépendance, qui n'est pas inhérente à la fonction du composant, mais souvent juste une décision architecturale.

Ainsi, lorsque des applications métier uniques sont créées sans dépendance vis-à-vis de l'automatisation du workflow, mais que votre contrôleur de workflow a des dépendances directes avec l'application métier, il doit être clair que l'automatisation du workflow est une «stratégie de haut niveau» et l'application métier est un composante "bas niveau". Notez que cette structure n'est pas obligatoire - si votre composant d'automatisation de workflow est un cadre général, qui n'est pas couplé à vos applications métier spécifiques non plus, mais peut être configuré pour servir différentes applications, alors vous avez déjà commencé à appliquer le DIP. Dans cette situation, la séparation «haut niveau» / «bas niveau» peut ne plus avoir de sens entre ces deux choses.

Ainsi, le nom "inversion de dépendance" est quelque peu trompeur - car les dépendances ne sont pas "inversées", mais complètement supprimées (ou pour être plus précis: changé de beeing compile time dependencies en run time dependencies).

J'utilise une image simple pour expliquer DIP. La vision classique du développement logiciel est un processus de construction avec chaque couche assise sur les couches inférieures qui la supportent. L'utilisation du principe d'inversion de dépendance ressemble plus à la construction d'un mobile.

Plutôt que les couches supérieures assis sur les couches inférieures, les couches supérieures de l'interface mobile avec les couches inférieures via la chaîne qui les relie. D'une certaine manière, les couches inférieures dépendent de cette interface pour le support (sans la chaîne, elles tomberaient). C'est DIP en bref.