Il y a 8 ans -
Temps de lecture 1 minute
Screencast : Dependency Inversion Principle
Dans ce screencast, nous réalisons un kata pour appliquer le Principe d’Inversion de Dépendance (Dependency Inversion Principle – DIP) de SOLID. Dans la programmation orientée objet, ce principe consiste à découpler les composants de haut niveau (la logique de l’application) des composants de bas niveau (les implementations). Lorsque ce principe est appliqué, cela rend l’application moins dépendante de ses implémentations et ainsi plus simple à maintenir et à faire évoluer.
Le DIP est normalement très visible dans les applications qui appliquent l’architecture Hexagonale ou même dans l’architecture Onion. C’est pourquoi nous avons passé un peu de temps à la fin de ce screencast à isoler les composants du domaine.
Vous pouvez retrouver le code source qui a été utilisé pour tourner ce screencast. La branche master représente l’état initial, la branche solution contient toutes les évolutions montrées dans la vidéo.
Mise à jour
Comme l’a bien dit Tristan dans les commentaires (ci-dessous), l’inversion des dépendances dans le cadre de l’exercice apparaît lorsque le package infrastructure devient dépendant du package domain (avant la logique applicative dépendait de l’implémentation technique). Cela nous a permis de découpler notre domaine fonctionnel des implémentations techniques qui n’en font pas partie, comme les clients GoogleMaps et OpenStreetMap.
Publié par Sébastian Le Merdy
Sébastian est entré chez Xebia en 2011 pour mettre en pratique le Software Development Done Right.
Il est passionné par le développement logiciel et les technologies innovantes et le met au service de l'utilisateur final à travers l'agilité dans les projets.
Vous pourrez peut-être le rencontrer lors d'un coding dojo ou une présentation de live coding.
Publié par Diego Lemos
Diego s’est forgé une solide expérience dans l'écosystème Java. Depuis, longtemps convaincu par l’agilité, Diego a participé à des nombreux projets agiles, d’abord en tant que développeur, puis en tant que scrum master et ensuite coach technique. Diego dispose d’un vaste panel de compétences sur l’ensemble de l’écosystème JVM, et notamment les solutions du monde open-source.
Passionné par l’informatique, il a eu l’occasion de d’intervenir sur des missions techniques très variées, notamment en tant que en tant que développeur frontend et sysadmin. Cela fait de Diego un expert technique full stack.
Il a joué un rôle important dans des projets de grande envergure, en tant que coach technique, notamment autour de la mise en place de pratiques tels que le Continuous Delivery à l’échelle. Aujourd’hui, Diego intervient principalement en tant que formateur, consultant et coach technique sur des sujets tels que le testing, le design du code, le software craftsmanship et le continuous delivery.
Blog personnel : http://diegolemos.net
Twitter : @dlresende.
Commentaire
7 réponses pour " Screencast : Dependency Inversion Principle "
Published by Anas , Il y a 8 ans
Quand on utilise Spring, on met en oeuvre une pratique qui consiste a systématiquement passer par des interfaces entre classe dépendantes. Si on veut que A instancie B, dans A on déclare une interface IB laquelle sera implémentée par B dans le fichier de conf de Spring. Cela permet de modifier l’implémentation B de IB par B’ dans le fichier de conf Spring sans toucher à la classe A. La pratique s’applique de manière récursive sur A avec une interface IA pour tout composant qui déclarerait A.
Qu’est ce qui différencie cette pratique de ce principe ?
Published by fay , Il y a 8 ans
Excellent screencast, plus claire que ça pour expliquer l’inversion du contrôle, tu meurs !
Published by Sébastian Le Merdy , Il y a 8 ans
Spring ne demande pas obligatoirement une interface pour pouvoir se faire injecter une dépendance. Cependant c’est souvent ce que l’on fait justement pour pouvoir changer d’implémentation par configuration.
Pour répondre à la question : l’injection de dépendances (notamment implémenté par Spring) est une solution concrète au principe d’inversion de contrôle. C’est un principe différent du principe d’inversion de dépendances décrit dans le screencast.
Published by Henri , Il y a 8 ans
J’ai bien aimé la démonstration mais je suis toujours chiffonné par une chose. L’absence de refactoring des tests. On les exécute mais on ne les regarde jamais. Par exemple, en faisant l’extraction de l’interface, il y avait des bonnes chances de pouvoir simplifier AppTest. Et c’est le cas. Il y a une apiKey Google qui traine à la fin.
Je vais dire comme Uncle Bob: « Le code de test c’est quand même du code. Il doit être traité avec le même soin ». Et là, peut être par soucis de brièveté, on les a un peu oublié
Published by Sébastian Le Merdy , Il y a 8 ans
Excellent point. Dans la vraie vie, j’aurai revu les fichiers modifiés avant de commiter et j’aurais sans doute revu le code de test à ce moment là.
Published by Tristan , Il y a 8 ans
Salut, pas mal votre vidéo.
Sauf erreur, vous ne dites pas à quel moment vous finissez de mettre en oeuvre l’inversion de dépendances.
Je dirais que ça aurait mérité un petit commentaire à ce moment : https://www.youtube.com/watch?v=wGqQ1UClVnI#t=391 où votre package « infrastructure » devient dépendant du package « domain » alors que jusque là le « domain » dépendait de l’ « infrastructure ».
Published by Diego Lemos , Il y a 8 ans
Merci Tristan pour ton feedback. En effet, j’ai re-regardé la vidéo et nous ne sommes pas très explicites sur ce point. J’ai mis à jour le billet de blog pour apporter des précisions.