Il y a 5 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 "

  1. Publié par , Il y a 5 ans

    Quand on utilise Spring, on met en oeuvre une pratique qui consiste a systmatiquement passer par des interfaces entre classe dpendantes. Si on veut que A instancie B, dans A on dclare une interface IB laquelle sera implmente par B dans le fichier de conf de Spring. Cela permet de modifier l’implmentation B de IB par B’ dans le fichier de conf Spring sans toucher la classe A. La pratique s’applique de manire rcursive sur A avec une interface IA pour tout composant qui dclarerait A.

    Qu’est ce qui diffrencie cette pratique de ce principe ?

  2. Publié par , Il y a 5 ans

    Excellent screencast, plus claire que a pour expliquer l’inversion du contrle, tu meurs !

  3. Publié par , Il y a 5 ans

    Spring ne demande pas obligatoirement une interface pour pouvoir se faire injecter une dpendance. Cependant c’est souvent ce que l’on fait justement pour pouvoir changer d’implmentation par configuration.
    Pour rpondre la question : l’injection de dpendances (notamment implment par Spring) est une solution concrte au principe d’inversion de contrle. C’est un principe diffrent du principe d’inversion de dpendances dcrit dans le screencast.

  4. Publié par , Il y a 5 ans

    J’ai bien aim la dmonstration mais je suis toujours chiffonn par une chose. L’absence de refactoring des tests. On les excute 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 mme du code. Il doit tre trait avec le mme soin ». Et l, peut tre par soucis de brivet, on les a un peu oubli

  5. Publié par , Il y a 5 ans

    Excellent point. Dans la vraie vie, j’aurai revu les fichiers modifis avant de commiter et j’aurais sans doute revu le code de test ce moment l.

  6. Publié par , Il y a 5 ans

    Salut, pas mal votre vido.

    Sauf erreur, vous ne dites pas quel moment vous finissez de mettre en oeuvre l’inversion de dpendances.

    Je dirais que a aurait mrit un petit commentaire ce moment : https://www.youtube.com/watch?v=wGqQ1UClVnI#t=391 o votre package « infrastructure » devient dpendant du package « domain » alors que jusque l le « domain » dpendait de l’ « infrastructure ».

  7. Publié par , Il y a 5 ans

    Merci Tristan pour ton feedback. En effet, j’ai re-regard la vido et nous ne sommes pas trs explicites sur ce point. J’ai mis jour le billet de blog pour apporter des prcisions.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.