Orienté Objet : L’art de l’inversion de dépendances
Et si je vous posais la question : Qu’est ce qui différencie le style de programmation Orienté Objet du style Procédural? Vous pouvez penser à l’encapsulation, l’héritage, le polymorphisme.. Oui, toutes ces notions sont intéressantes. Mais ce ne sont autant pas ces points qui font la différence.
Le bénéfice majeur de l’Orienté Objet est en fait la gestion des dépendances.
Les deux types de dépendances
Imaginez deux modules A et B. Imaginez une fonction x du Module A qui appelle une fonction y du Module B. Ceci veut dire qu’il y’a une dépendance du module A au Module B.
En fait, il y’a deux types de dépendances entre les Modules A et B. Clairement, à l’exécution, le Module A dépend du Module B, il y’a donc une dépendance au niveau exécution (Runtime Dependency). Ceci est encore appelé “Structure de Contrôle” (Flow Of Control).
Mais il y’a une autre dépendance. Le code source dans le module A (dans les langages comme Java, C# et C++) doit contenir des déclarations comme “import”, “using” ou autre, qui réfèrent au Module B. Ceci est le type de dépendance qui nous intéresse : La dépendance au niveau du code source.
Que se passe t’il si vous déployez le module A et le Module B séparément? Par exemple, si le Module B est un “plugin” au Module A, si le Module A a une dépendance au niveau du code source au Module B, alors les deux ne peuvent pas être déployés séparément, ou même compilés séparément. Un changement dans le Module B implique forcément la recompilation et le redéploiement du Module A.
La Magie de l’Orienté Objet!
L’O.O. nous permet de faire quelque chose de spectaculaire! Nous pouvons inverser la dépendance du code source sans changer la dépendance d’exécution! Comment?
- Nous supprimons la dépendance originale
- Nous insérons une “Interface Polymorphique” entre A et B
- Nous faisons que A dépend de l’interface, et que B dérive de l’interface.
Ceci change le sens de la dépendance de code source pour pointer maintenant de B vers A. Maintenant, La dépendance de B pointe Dans le sens inverse que la dépendance d’exécution.
On dit que
- La dépendance du code source pointe dans le sens contraire que la structure de contrôle.
- Le Code source Oppose la Structure de Contrôle.
Ceci permet aux Modules A et B d’être déployés séparément. Le module B peut se “pluguer” au Module A. En fait, le Module A peut avoir plusieurs dépendances de ce genre. Le Code source du Module A n’a pas de connaissance sur ces modules.
Et Ceci est juste une des bonnes choses que l’Orienté Objet nous apporte : L’indépendance du déploiement.
Comme nous avons vu dans mon dernier Post, nous avons utilisé ce principe pour découpler le mécanisme de livraison du Module Principal contenant les cas d’utilisation du système.
Nous allons essayer de mieux exposer le principe d’Inversion de Contrôle dans des prochains Posts. Pour le moment, ceci va être suffisant pour continuer notre histoire sur le Partitionnement des composants (Boundaries) dans une architecture Orientée Objet afin de répondre à notre question “Comment découpler la couche Base de données dans l’architecture.”
