L'Agilitateur - Je n'aime pas les conteneurs d'injection de dépendances - CommentairesCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearJe n'aime pas les conteneurs d'injection de dépendances - Oazurn:md5:415060b57c1d5d1ef21b15e6600b9f642012-02-16T12:54:46+01:002012-02-16T12:54:46+01:00Oaz<p>Pas tout à fait d'accord sur la similarité avec un Service Locator. Sur la forme, oui, parce qu'on va chercher le truc que l'on veut "s'auto-injecter" mais sur le fond c'est très différent (un package ne référence que les bindings qui le concernent alors qu'un Service Locator référence tous les bindings possibles)</p>
<p>Et oui, ce qui compte en premier, c'est le DIP, peu importe comment on le réalise.<br />Mais dès que le DIP est acquis (ce que je crois pas grand monde ne conteste), ce qui m'importe le plus c'est de ne <ins>pas</ins> mettre un quelconque outil implémentant ce DIP au coeur de mon système. Il faut inverser <ins>toutes</ins> les dépendances, y compris celles sur un outil d'inversion de dépendances...</p>Je n'aime pas les conteneurs d'injection de dépendances - Denisurn:md5:77f6a63490c0974c07d71fb0087d078a2012-02-16T00:12:21+01:002012-02-16T11:48:12+01:00Denis<p>Dans le code que tu proposes, je vois plus un Service Locator qu'un DI container.</p>
<p>Mais je suis entièrement d'accord sur le principe : l'important est d'inverser les dépendances (le D de SOLID), et l'utilisation de DI n'est qu'une option, qu'un moyen, pas une fin.</p>
<p>C'est pourquoi certains proposent le "poor man's DI" : <a href="http://blog.robbowley.net/2010/01/18/not-so-poor-mans-dependency-injection" title="http://blog.robbowley.net/2010/01/18/not-so-poor-mans-dependency-injection/," rel="ugc nofollow">http://blog.robbowley.net/2010/01/18/not-so-poor-mans-dependency-injection/</a> ce qui est le sujet de débats enragés : <a href="http://lostechies.com/chadmyers/2009/07/14/just-say-no-to-poor-man-s-dependency-injection/" title="http://lostechies.com/chadmyers/2009/07/14/just-say-no-to-poor-man-s-dependency-injection/" rel="ugc nofollow">http://lostechies.com/chadmyers/200...</a></p>Je n'aime pas les conteneurs d'injection de dépendances - Oazurn:md5:b5bf193af856ae741e1a3af2625f72352012-02-15T18:00:59+01:002012-02-15T18:00:59+01:00Oaz<p>Bon... Je crois que je n'ai pas complètement réussi à faire passer l'idée que je voulais faire passer.<br />Ce n'est qu'un embryon de solution et d'ailleurs ce n'est même pas une solution, c'est juste une façon de voir les choses.</p>
<p>L'injection de dépendances, je préfère la bâtir en utilisant des concepts qui sont propres à mon logiciel et que l'on peut agrémenter en fonction des besoins.<br />Cela pourrait même aller jusqu'à l'utilisation d'un DI externe <ins>mais qui resterait caché derrière ces concepts</ins>. Donc la solution proposée n'est pas limitée, bien au contraire.</p>
<p>Ceci étant dit, je n'ai jamais eu besoin d'aller jusque là comme quoi les besoins dépendent du contexte et sont peut être moins étendus qu'on peut le penser.</p>
<p>Mais je pense qu'il y a là un point important : les frameworks ou outils externes (peu importe comment on les nomme) doivent rester des détails d'implémentation amovibles.<br />Ils doivent être complètement disjoints des concepts architecturaux du logiciel et ils ne doivent intervenir que lorsque leur nécessité est avérée.</p>Je n'aime pas les conteneurs d'injection de dépendances - sfuiurn:md5:06695e795acb5c2f41596a48db8642d62012-02-15T16:58:57+01:002012-02-15T16:58:57+01:00sfui<p>Faire facilement n'importe quoi c'est déjà possible simplement avec le langage. C'est pour cela que l'on se fixe des principes. Libre à toi de les appliquer ou non…<br />
Avec Guice on peut faire des trucs très sympas (couplé par exemple avec le ServiceLoader) et des trucs… vraiment crades ;)<br />
Bien qu'élégante, j'ai peur que ta solution soit légèrement limité dans certains cas.<br />
Donc, comme tu l'as dit, connaître des frameworks est une bonne chose et, bien sûr, connaître les principes de la POO est vitale.</p>Je n'aime pas les conteneurs d'injection de dépendances - Oazurn:md5:de5011cd70962a4a4050a323e70056b12012-02-15T14:30:09+01:002012-02-15T14:30:09+01:00Oaz<p>Je n'ai pas de problème avec la syntaxe. C'est plutôt avec les concepts que je pense avoir du mal.<br />(Je n'ai jamais utilisé Guice donc ce que peux peux écrire doit être pris avec des pincettes)</p>
<p>Il me semble que c'est la notion de "module" qui me pose plus de problèmes.</p>
<p>Si je prends la notion de package telle que définie par Uncle Bob dans <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod" rel="ugc nofollow">Principles of OOP</a>,c'est à dire un .jar ou un .dll, alors toute notion supplémentaire servant à grouper des classes me parait superflue, voire dangereuse si elle permet de grouper les choses différemment.<br />Si en pratique le développeur s'en tient strictement à avoir 1 .jar = 1 AbstractModule alors pas de problème : l'AbstractModule représente ce que j'appelle <code class="csharp plain">IProvideCustomDetails</code> dans mon exemple.<br />(et du coup le "bind" se limite à définir des arguments de construction puisque dans un package on ne trouve qu'une et une seule implémentation d'une interface donnée)</p>
<p>Je crois fermement que l'injection de dépendances et les notions de packages cohesion / packages coupling doivent être fortement liées.<br />Le risque d'un framework, c'est de pouvoir faire trop facilement n'importe quoi...</p>Je n'aime pas les conteneurs d'injection de dépendances - Jean-Baptisteurn:md5:97bbab449d8a22aa615b77901883c4212012-02-15T11:31:48+01:002012-02-15T11:31:48+01:00Jean-Baptiste<p>par défaut, si tu ne lui dis rien, quand tu lui demandes une instance, il prend la première implémentation qu'il trouve.</p>
<p>La syntax du bind je la trouve très explicite, que lui reproches-tu ? </p>Je n'aime pas les conteneurs d'injection de dépendances - Oazurn:md5:3e244e3a1d773add8161e01719a0bba82012-02-15T11:01:27+01:002012-02-15T11:01:27+01:00Oaz<p>Ah bon ?<br />Si c'est le cas, c'est bien dommage de ne pas trouver cela facilement dans la doc de Guice. Tous ces "bind(machin).to(truc)" ça me file des boutons.</p>Je n'aime pas les conteneurs d'injection de dépendances - Jean-Baptisteurn:md5:6653124bbea1d876a60b864ca99478812012-02-15T09:08:09+01:002012-02-15T09:08:09+01:00Jean-Baptiste<p>Je suis bien d'accord.</p>
<p>Si un jour tu viens du côté de java, je pense que tu vas adorer Guice, il peut se comporter par défaut plus ou moins exactement comme ce que tu viens de décrire.</p>