J'ai récemment travaillé sur un projet Python où nous avons fait beaucoup d'injection de dépendances (parce que nous devons pour que l'application soit testable), mais nous n'avons utilisé aucun framework. Parfois, c'était un peu fastidieux de câbler toutes les dépendances manuellement, mais dans l'ensemble, cela fonctionnait très bien.

Lorsqu'un objet devait être créé à plusieurs endroits, nous avions simplement une fonction (parfois une méthode de classe de cet objet) pour créer une instance de production. Cette fonction était appelée chaque fois que nous avions besoin de cet objet.

Dans les tests, nous avons fait la même chose: si plusieurs fois nous devions créer une «version de test» d'un objet (c'est-à-dire une instance réelle soutenue par des objets factices), nous avions une fonction pour créer cette «version de test» d'une classe, à utiliser dans les tests.

Comme je l'ai dit, cela fonctionnait généralement bien.

J'entre maintenant dans un nouveau projet Java, et nous décidons d'utiliser un framework DI ou de faire DI manuellement (comme dans le projet précédent).

Veuillez expliquer en quoi le travail avec un framework DI sera différent, et de quelles manières il est meilleur ou pire que l'injection manuelle de dépendance «vanille».

Edit: Je voudrais également ajouter à la question: avez-vous été témoin d'un projet de «niveau professionnel» qui fait de l'ID manuellement, sans cadre?

La clé des conteneurs DI est l'abstraction . Les conteneurs DI résument cette préoccupation de conception pour vous. Comme vous pouvez le deviner, cela a un impact notable sur le code, souvent traduit par un nombre moins important de constructeurs, de setters, d'usines et de builders. En conséquence, ils rendent votre code plus faiblement couplé (en raison de l' IoC sous-jacent ), plus propre et plus simple. Mais pas sans frais.

Arrière-plans

Il y a des années, une telle abstraction nous obligeait à écrire différents fichiers de configuration ( programmation déclarative ). C'était fantastique de voir le nombre de LOC diminuer considérablement, mais alors que les LOCS diminuaient, le nombre de fichiers de configuration augmentait légèrement. Pour les projets de moyenne ou petite envergure, ce n'était pas du tout un problème, mais pour les grands projets, avoir "l'assemblage du code" dispersé à 50% entre le code et les descripteurs XML est devenu une douleur dans le ... Néanmoins, le principal problème était le le paradigme lui-même. C'était assez rigide parce que les descripteurs laissaient peu d'espace pour les personnalisations.

Le paradigme s'est progressivement déplacé vers la convention sur la configuration , qui échange les fichiers de configuration contre des annotations ou des attributs. Il maintient notre code plus propre et plus simple tout en nous offrant la flexibilité que XML ne pouvait pas.

Il s'agit probablement de la différence la plus importante concernant la façon dont vous travailliez jusqu'à présent. Moins de code et plus de magie.

Sur le plan négatif ...

La convention sur la configuration rend l'abstraction si lourde que vous savez à peine comment elle fonctionne. Cela semble parfois magique et voici encore un inconvénient. Une fois que cela fonctionne, de nombreux développeurs ne se soucient pas de la façon dont cela fonctionne.

C'est un handicap pour ceux qui ont appris DI avec des conteneurs DI. Ils ne comprennent pas pleinement la pertinence des modèles de conception, les bonnes pratiques et les principes qui ont été abstraits par le conteneur. J'ai demandé aux développeurs s'ils étaient familiarisés avec DI et ses avantages et ils ont répondu: - Oui, j'ai utilisé Spring IoC -. (Qu'est-ce que ça signifie?!?)

On peut être d'accord ou non avec chacun de ces "inconvénients". À mon humble avis, il est indispensable de savoir ce qui se passe dans votre projet. Sinon, nous ne le comprenons pas complètement. Est aussi de savoir à quoi sert DI et d'avoir une idée de la façon de l'implémenter est un plus à considérer.

Du coté positif...

Productivité en un mot . Les cadres nous permettent de nous concentrer sur ce qui compte vraiment. Le métier de l'application.

Malgré les lacunes commentées, pour beaucoup d'entre nous (dont le travail est conditionné par les délais et les coûts), ces outils sont une ressource inestimable. À mon avis, cela devrait être notre principal argument en faveur de la mise en œuvre d'un conteneur DI. Productivité .

Essai

Que ce soit si nous implémentons des DI purs ou des conteneurs, les tests ne seront pas un problème. Plutôt l'inverse. Les mêmes conteneurs nous fournissent souvent les simulations pour les tests unitaires hors de la boîte. Au fil des ans, j'ai utilisé mes tests comme thermomètres. Ils me disent si je me suis beaucoup appuyé sur les installations de conteneurs. Je dis cela parce que ces conteneurs peuvent initialiser des attributs privés sans setters ni constructeurs. Ils peuvent injecter des composants presque partout!

Cela semble tentant non? Faites attention! Ne tombez pas dans le piège !!

Suggestions

Si vous décidez de mettre en œuvre des conteneurs, je vous suggère fortement de respecter les bonnes pratiques. Continuez à implémenter les constructeurs, les setters et les interfaces. Appliquez le framework / conteneur pour les utiliser . Cela facilitera les migrations possibles vers un autre framework ou supprimera le framework actuel. Cela peut réduire considérablement la dépendance à l'égard du conteneur.

Concernant ces pratiques:

• Injection de dépendance: injection de terrain vs injection de constructeur?

Quand utiliser les conteneurs DI

Ma réponse va être biaisée par sa propre expérience qui est principalement en faveur des conteneurs DI (comme je l'ai dit, je suis fortement concentré sur la productivité, donc je n'ai jamais eu besoin d'une DI pure. Bien au contraire).

Je pense que vous trouverez un article intéressant de Mark Seeman sur ce sujet, qui répond également à la question de savoir comment implémenter la DI pure .

Enfin, si nous parlions de Java, j'envisagerais d' abord de jeter un œil au JSR330 - Dependency Injection .

Résumer

Bénéfices :

• Réduction des coûts et gain de temps. Productivité.
• Un plus petit nombre de composants.
• Le code devient plus simple et plus propre.

Désavantages :

• DI est délégué à des bibliothèques tierces. Nous devons être conscients de leurs compromis, de leurs forces et de leurs faiblesses.
• Courbe d'apprentissage.
• Ils vous font vite oublier de bonnes habitudes.
• Augmentation des dépendances du projet (plus de libs)
• Les conteneurs basés sur la réflexion nécessitent plus de ressources (mémoire). C'est important si nous sommes limités par les ressources.

Différences avec DI pur :

• Moins de code et plus de fichiers de configuration ou d'annotations.

D'après mon expérience, un cadre d'injection de dépendances entraîne un certain nombre de problèmes. Certains problèmes dépendront du cadre et des outils. Il peut y avoir des pratiques qui atténuent les problèmes. Mais ce sont les problèmes que j'ai rencontrés.

Objets non globaux

Dans certains cas, vous souhaitez injecter un objet global: un objet qui n'aura qu'une seule instance dans votre application en cours d'exécution. Cela peut être a MarkdownToHtmlRendererer, a DatabaseConnectionPool, l'adresse de votre serveur api, etc. Pour ces cas, les frameworks d'injection de dépendances fonctionnent très simplement, il vous suffit d'ajouter la dépendance nécessaire à votre constructeur et vous l'avez.

Mais qu'en est-il des objets qui ne sont pas globaux? Et si vous avez besoin de l'utilisateur pour la demande actuelle? Que faire si vous avez besoin de la transaction de base de données actuellement active? Et si vous avez besoin de l'élément HTML correspondant à la div qui contient un formulaire dans lequel se trouve une zone de texte qui vient de déclencher un événement?

La solution que j'ai vue utilisée par les frameworks DI est les injecteurs hiérarchiques. Mais cela rend le modèle d'injection plus compliqué. Il devient plus difficile de comprendre exactement ce qui sera injecté à partir de quelle couche de la hiérarchie. Il devient difficile de dire si un objet donné existera par application, par utilisateur, par demande, etc. Vous ne pouvez plus simplement ajouter vos dépendances et le faire fonctionner.

Bibliothèques

Souvent, vous voudrez avoir une bibliothèque de code réutilisable. Cela comprendra également les instructions sur la façon de construire des objets à partir de ce code. Si vous utilisez un framework d'injection de dépendances, cela inclura généralement des règles de liaison. Si vous souhaitez utiliser la bibliothèque, vous ajoutez leurs règles de liaison aux vôtres.

Cependant, divers problèmes peuvent en résulter. Vous pouvez vous retrouver avec la même classe liée à différentes implémentations. La bibliothèque peut s'attendre à ce que certaines liaisons existent. La bibliothèque peut remplacer certaines liaisons par défaut, ce qui fait que votre code fait une chose étrange. Votre code peut remplacer une liaison par défaut, ce qui fait que le code de la bibliothèque fait des choses étranges.

Complexité cachée

Lorsque vous écrivez manuellement des usines, vous avez une idée de la façon dont les dépendances de l'application s'emboîtent. Lorsque vous utilisez un framework d'injection de dépendances, vous ne voyez pas cela. Au lieu de cela, les objets ont tendance à croître de plus en plus de dépendances jusqu'à ce que tout dépend tôt ou tard de tout.

Prise en charge IDE

Votre IDE ne comprendra probablement pas le cadre d'injection de dépendance. Avec les usines manuelles, vous pouvez trouver tous les appelants d'un constructeur pour comprendre tous les endroits où l'objet pourrait être construit. Mais il ne trouvera pas les appels générés par le framework DI.

Conclusion

Qu'obtenons-nous d'un cadre d'injection de dépendances? Nous arrivons à éviter un passe-partout simple nécessaire pour instancier des objets. Je suis pour l'élimination du passe-partout simple. Cependant, le maintien d'un passe-partout simple d'esprit est facile. Si nous voulons remplacer ce passe-partout, nous devons insister pour le remplacer par quelque chose de plus facile. En raison des diverses questions dont j'ai discuté ci-dessus, je ne pense pas que les cadres (du moins en l'état) correspondent au projet de loi.

Est-ce que Java + injection de dépendances = framework requis?

Non.

Qu'est-ce qu'un framework DI m'achète?

La construction d'objets se passe dans un langage qui n'est pas Java.

Si les méthodes d'usine sont assez bonnes pour vos besoins, vous pouvez faire DI en java complètement sans framework en 100% pojo java authentique. Si vos besoins vont au-delà, vous avez d'autres options.

Les modèles de conception de Gang of Four accomplissent beaucoup de grandes choses, mais ont toujours eu des faiblesses en ce qui concerne les modèles de création. Java lui-même présente quelques faiblesses. Les cadres DI aident vraiment à cette faiblesse créative plus qu'ils ne le font avec les injections réelles. Vous savez déjà comment faire cela sans eux. Le bien qu'ils vous feront dépendra de l'aide dont vous avez besoin pour la construction d'objets.

Il existe de nombreux modèles de création qui sont apparus après le Gang of Four. Le générateur Josh Bloch est un merveilleux hack autour du manque de paramètres nommés de Java. Au-delà de cela, les constructeurs iDSL offrent beaucoup de flexibilité. Mais chacun d'entre eux représente un travail et un passe-partout importants.

Les cadres peuvent vous sauver d'une partie de cet ennui. Ils ne sont pas sans inconvénients. Si vous ne faites pas attention, vous pouvez vous retrouver dépendant du framework. Essayez de changer de framework après en avoir utilisé un et voyez par vous-même. Même si vous conservez en quelque sorte le xml ou les annotations génériques, vous pouvez finir par prendre en charge ce qui sont essentiellement deux langues que vous devez mentionner côte à côte lorsque vous publiez des travaux de programmation.

Avant de devenir trop amoureux de la puissance des frameworks DI, prenez un peu de temps et étudiez d'autres frameworks qui vous offrent des capacités que vous pourriez autrement penser avoir besoin d'un framework DI. Beaucoup se sont diversifiés au-delà de la simple DI . Considérez: Lombok , AspectJ et slf4J . Chacun chevauche certains cadres DI, mais chacun fonctionne très bien seul.

Si le test est vraiment la force motrice derrière cela, veuillez regarder: jUnit (n'importe quelle xUnit vraiment) et Mockito (n'importe quelle maquette vraiment) avant de commencer à penser qu'un cadre DI devrait prendre le dessus sur votre vie.

Vous pouvez faire ce que vous voulez, mais pour un travail sérieux, je préfère une boîte à outils bien remplie à un couteau suisse. J'aimerais qu'il soit plus facile de dessiner ces lignes, mais certains ont travaillé dur pour les brouiller. Rien de mal à cela, mais cela peut rendre ces choix difficiles.

La création de classes et leur affectation de dépendances fait partie du processus de modélisation, les parties amusantes. C'est la raison pour laquelle la plupart des programmeurs aiment la programmation.

Décider quelle implémentation sera utilisée et comment les classes sont construites est une chose qui devra être implémentée d'une manière ou d'une autre et fera partie de la configuration de l'application.

L'écriture manuelle des usines est un travail fastidieux. Les infrastructures DI facilitent la tâche en résolvant automatiquement les dépendances qui peuvent être résolues et en exigeant une configuration pour celles qui ne le sont pas.

L'utilisation d'IDE modernes vous permet de parcourir les méthodes et leurs utilisations. Avoir des usines écrites manuellement est assez bon, car vous pouvez simplement mettre en évidence le constructeur d'une classe, montrer ses usages, et cela vous montrera tous les endroits où et comment la classe spécifique est en cours de construction.

Mais même avec le framework DI, vous pouvez avoir une place centrale, comme la configuration de construction de graphe d'objet (OGCC à partir de maintenant), et si une classe dépend de dépendances ambiguës, vous pouvez simplement regarder OGCC et voir comment une classe spécifique est en cours de construction juste là.

Vous pourriez objecter que vous pensez personnellement pouvoir voir les usages d'un constructeur spécifique est un grand plus. Je dirais que ce qui ressort mieux pour vous n'est pas seulement subjectif, mais vient surtout de l'expérience personnelle.

Si vous aviez toujours travaillé sur des projets qui s'appuyaient sur des frameworks DI, vous ne le sauriez vraiment que lorsque vous vouliez voir une configuration d'une classe, vous regarderiez toujours OGCC et n'essaieriez même pas de voir comment les constructeurs sont utilisés , car vous savez que les dépendances sont toutes câblées automatiquement de toute façon.

Naturellement, les frameworks DI ne peuvent pas être utilisés pour tout et de temps en temps, vous devrez écrire une ou deux méthodes d'usine. Un cas très courant est la construction d'une dépendance pendant l'itération sur une collection, où chaque itération fournit un indicateur différent qui devrait produire une implémentation différente d'une interface par ailleurs commune.

En fin de compte, tout dépendra très probablement de vos préférences et de ce que vous êtes prêt à sacrifier (soit en écrivant du temps dans les usines, soit en transparence).

Expérience personnelle (avertissement: subjectif)

Parlant en tant que développeur PHP, bien que j'aime l'idée derrière les frameworks DI, je ne les ai utilisés qu'une seule fois. C'est à ce moment-là qu'une équipe avec laquelle je travaillais était censée déployer une application très rapidement et nous ne pouvions pas perdre de temps à écrire des usines. Nous avons donc simplement choisi un framework DI, l'avons configuré et cela a fonctionné d'une manière ou d'une autre .

Pour la plupart des projets, j'aime que les usines soient écrites manuellement parce que je n'aime pas la magie noire qui se passe dans les frameworks DI. J'étais le responsable de la modélisation d'une classe et de ses dépendances. C'est moi qui décidais pourquoi le design ressemblait à ça. Je serai donc celui qui construit correctement la classe (même si la classe prend des dépendances dures, telles que des classes concrètes au lieu d'interfaces).

Personnellement, je n'utilise pas de conteneurs DI et je ne les aime pas. J'ai quelques autres raisons à cela.

Il s'agit généralement d'une dépendance statique. Il ne s'agit donc que d'un localisateur de services avec tous ses inconvénients. Ensuite, en raison de la nature des dépendances statiques, elles sont masquées. Vous n'avez pas besoin de vous en occuper, ils sont déjà en quelque sorte là, et c'est dangereux, car vous cessez de les contrôler.

Il rompt les principes de la POO , tels que la cohésion et la métaphore de l'objet Lego-brick de David West .

Donc, la construction de l'objet entier aussi près que possible du point d'entrée du programme est la voie à suivre.

Comme vous l'avez déjà remarqué: selon la langue que vous utilisez, il existe différents points de vue, différentes manières de gérer des problèmes similaires.

En ce qui concerne l'injection de dépendances, cela se résume à ceci: l'injection de dépendances n'est, comme le terme le dit, rien de plus que de mettre les dépendances dont un objet a besoin dans cet objet - contrairement à l'autre: laisser l'objet lui-même instancier des instances d'objets dont il dépend. Vous dissociez la création et la consommation d'objets pour gagner en flexibilité.

Si votre conception est bien structurée, vous avez généralement peu de classes avec de nombreuses dépendances, donc le câblage des dépendances - à la main ou par un framework - devrait être relativement facile et la quantité de passe-partout pour écrire les tests devrait être facile à gérer.

Cela dit, il n'y a pas besoin d'un cadre DI.

Mais pourquoi voulez-vous quand même utiliser un framework?

I) Évitez le code passe-partout

Si votre projet prend de la taille, où vous ressentez la douleur d'écrire des usines (et des instatiations) encore et encore, vous devez utiliser un cadre DI

II) Approche déclinative de la programmation

Lorsque Java programmait autrefois avec XML, c'est maintenant: saupoudrer Fairydust d'annotations et la magie opère .

Mais sérieusement: je vois un net avantage à cela. Vous communiquez clairement votre intention en disant ce qui est nécessaire plutôt que où le trouver et comment le construire.

tl; dr

Les frameworks DI n'améliorent pas votre base de code comme par magie, mais cela aide à rendre le code beau vraiment net . Utilisez-le lorsque vous en ressentez le besoin. À un certain moment de votre projet, cela vous fera gagner du temps et évitera les nausées.

Oui. Vous devriez probablement lire le livre de Mark Seemann intitulé "Dependency Injection". Il décrit quelques bonnes pratiques. Sur la base de certains de vos propos, vous pourriez en bénéficier. Vous devez viser à avoir une racine de composition ou une racine de composition par unité de travail (par exemple, une demande Web). J'aime sa façon de penser que tout objet que vous créez est considéré comme une dépendance (tout comme n'importe quel paramètre d'une méthode / constructeur), vous devez donc faire très attention où et comment vous créez des objets. Un cadre vous aidera à garder ces concepts clairs. Si vous lisez le livre de Mark, vous trouverez plus que la réponse à votre question.

Oui, lorsque je travaille en Java, je recommanderais un framework DI. Il y a plusieurs raisons à cela:

• Java possède plusieurs très bons packages DI qui offrent une injection de dépendances automatisée et sont également généralement fournis avec des capacités supplémentaires plus difficiles à écrire manuellement que les DI simples (par exemple, les dépendances étendues qui permettent une connexion automatique entre les étendues en générant du code pour rechercher dans quelle étendue devrait être utilisez un d pour trouver la version correcte de la dépendance pour cette portée - ainsi, par exemple, les objets de portée d'application peuvent se référer à ceux de portée de demande).

• les annotations java sont extrêmement utiles et fournissent un excellent moyen de configurer les dépendances

• la construction des objets java est trop verbeuse par rapport à ce à quoi vous êtes habitué en python; L'utilisation d'un cadre ici permet d'économiser plus de travail que dans un langage dynamique.

• Les frameworks java DI peuvent faire des choses utiles comme générer automatiquement des mandataires et des décorateurs qui fonctionnent plus en Java qu'un langage dynamique.

Si votre projet est assez petit et que vous n'avez pas beaucoup d'expérience avec le DI-Framework, je recommanderais de ne pas utiliser le framework et de le faire manuellement.

Raison: J'ai déjà travaillé dans un projet qui utilisait deux bibliothèques qui avaient des dépendances directes avec différents cadres di. ils avaient tous deux un code spécifique au framework comme di-give-me-an-instance-of-XYZ. Autant que je sache, vous ne pouvez avoir qu'une seule implémentation active de di-framework à la fois.

avec un code comme celui-ci, vous pouvez faire plus de mal que d'avantages.

Si vous avez plus d'expérience, vous supprimerez probablement le di-framwork par une interface (usine ou servicelocator) de sorte que ce problème n'existera plus et que le cadre di profitera davantage à ce mal.