Existe-t-il des preuves que l'utilisation de l'injection de dépendance améliore les résultats en génie logiciel?

Malgré sa popularité, existe-t-il des preuves empiriques montrant que l'injection de dépendance (et / ou l'utilisation d'un conteneur DI) aide, par exemple, à réduire le nombre de bogues, à améliorer la maintenabilité ou à augmenter la vitesse de développement sur des projets logiciels réels?

TLDR

Les données empiriques ne sont pas pertinentes. Les outils et les pratiques (comme DI) résolvent des problèmes particuliers . Comprenez vos problèmes, apprenez à utiliser les outils, et cela deviendra évident lorsqu'un outil est utile - et vous serez en mesure d'expliquer les résultats de manière beaucoup plus prophétique que toutes les données empiriques généralisées et agrégées.

Et maintenant, avec beaucoup plus de verbosité ...

Existe-t-il des preuves empiriques?

Bien sûr, probablement. Ou du moins peut-être. Mais qui s'en soucie? Ce n'est pas pertinent.

Une analyse statistique coûts-avantages de l'ID peut être intéressante d'un point de vue académique, mais elle ne prédit pas nécessairement le succès individuel. Les résultats agrégés masquent les succès et les échecs individuels . Et, je pourrais faire valoir que les données concernant les pratiques "évangéliques" sont particulièrement toxiques. Ces disciplines ont tendance à attirer les fanatiques et les fous, les deux qui obscurcissent l'impact net d'une mise en œuvre « pure », et non dont vous pourriez être!

Alors, comment savons-nous que l'injection de dépendance est valable du tout?

Bonne question! GRANDE question, en fait. Et je suis avec vous - je déteste perdre du temps et des efforts mentaux sur les "meilleures pratiques" dogmatiques que personne ne peut justifier. Donc, je suis content que vous ayez demandé.

Euh. Mais, voici le problème embarrassant ... En général , vous ne savez pas . Et, encore plus embarrassant, votre code peut ne pas s'améliorer en aucune façon en introduisant DI.

HALETER!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

Alors, peut-être que maintenant vous vous demandez ...

Pourquoi devrais-je me soucier des choses qui n'ont pas été prouvées euh nuthin '!?

Tout d'abord, contentons-nous - de chaque côté du débat - de nous calmer. Je peux vous assurer qu'entre le dogmatisme et le scepticisme se trouve un beau paradis de raison et de pondération. (Et le poste excentrique SE.SE occasionnel.) Et, le POAP peut vous y conduire.

... J'entends par là le principe d'application des principes :

Les principes, les modèles et les pratiques ne sont pas des finalités. La bonne et correcte application de chacun est donc inspirée et contrainte par un objectif supérieur, plus final.

Vous devez comprendre pourquoi vous faites ce que vous faites!

(Le POAP n'est pas exempté du POAP.)

^{(Je dirais, "c'est moi qui souligne", mais ça vient de mon "blog" de toute façon. Donc, tout est à moi!)}

Permettez-moi de réitérer le point principal ici: vous devez comprendre pourquoi vous faites ce que vous faites.

Et peut-être pour clarifier, il n'est généralement pas logique de prendre un "quelque chose" donné (comme l'injection de dépendance), et de l'utiliser sans déjà comprendre quel problème il résout - pour vous en particulier. Si vous comprenez vos problèmes et comment fonctionne le «quelque chose» (comme l'ID), il sera quelque peu «évident» à quel point le «quelque chose» est utile, peu importe ce que suggèrent les données empiriques généralisées et agrégées.

Si l'utilité ou la non- utilité de DI pour vous n'est pas évidente - ou du moins au-delà de vos pouvoirs de raisonnement - vous ne comprenez pas DI, ou vous ne comprenez pas vos propres problèmes.

Prenons une "parabole" du monde réel.

Nous devons construire une boîte. Nous avons du bois. Nous avons des clous. Et, nous avons deux outils: un marteau à griffes standard et un tournevis .

Maintenant, nous pouvons avoir des données empiriques générales pour montrer que les boîtes construites avec des tournevis sont globalement des boîtes beaucoup plus robustes que celles construites avec des marteaux. Mais, si vous essayez de visser ces clous, vous ne vous retrouverez pas du tout avec une boîte. Et, si vous essayez de les frapper avec le tournevis, vous pourriez éventuellement les faire entrer; mais cela nécessitera beaucoup plus de temps et d'efforts, et le résultat final sera moins précis (et robuste) que si vous aviez simplement utilisé le marteau.

Et, si vous avez déjà vu quelqu'un utiliser l'un ou l'autre de ces outils auparavant, et si vous comprenez à quoi ressemble une boîte, la décision est évidente.

Télékinésie!

Euh ... hmm ...

Oui, alors, quel problème l'injection de dépendance résout-elle?

Il empêche le code rigide et non configurable, qui est donc souvent non testable .

Il le fait en permettant d' invoquer du code pour décider avec quels objets un module fonctionne. Et je sais que vous y pensez, et vous avez raison: ce n'est même pas un nouveau concept à distance. Les paramètres de méthode / fonction existent depuis l'algèbre.

Nous avons commencé à évangéliser le passage des paramètres de base, en l'appelant "injection de dépendance", une fois que nous avons accumulé et hérité suffisamment de code pour voir nos déséquilibres. Les montagnes de code sur lesquelles nous étions assis ne pouvaient pas être facilement modifiées, testées ou même réutilisées , simplement parce que les dépendances étaient cachées.

Par conséquent, la croisade zélée pour l'injection de dépendance ...

K. Mais, je peux passer des arguments très bien. Pourquoi les cadres ?

Si je comprends bien, les cadres DI résolvent principalement le problème de l'accumulation de plaques passe-partout (en raison d'un DI trop zélé, IMO) - en particulier lorsqu'il existe des dépendances "par défaut" standard pour tous les modules qui en ont besoin. Les frameworks DI font des choses magiques (potentiellement même coquines!) Pour glisser ces dépendances par défaut lorsqu'elles ne sont pas explicitement transmises au moment de l'invocation. (Même effet qu'un localisateur de service lorsqu'il est utilisé de cette manière, attention!)

L'injection de dépendance, en tant que «discipline», est en réalité très difficile à réaliser. Il ne s'agit pas d'utiliser DI ou non; il est une question de savoir quelles dépendances sont susceptibles de changer ou besoin moqueur et injecter ceux . Et puis, il s'agit de décider si DI convient mieux que certaines alternatives, comme l'emplacement du service ...

Mais, je vous encourage à Google il , peut - être voir cette réponse SO , peut - être parler à un super-développeur expérimenté et réussi dans votre secteur d' activité, ainsi que des exemples de spécifiques à poste CR.SE .

J'ai recherché Google, Google Scholar, ACM et IEEE Voici les documents que j'ai pu trouver:

• Cadres d'injection de dépendance: une amélioration de la testabilité? . Il fait valoir que la "testabilité" peut être définie comme une "faible cohésion". Il indique que DI conduit à une cohésion plus faible, une cohésion plus faible est corrélée avec une couverture de test plus élevée, et qu'une couverture de test plus élevée est corrélée avec plus de défauts trouvés. Il dit que, sur cette base, DI améliore la testabilité.

  Je n'aime pas ça pour deux raisons. Tout d'abord, il dit "A est corrélé avec B, B est corrélé avec C, donc A cause C", ce qui est quelques étapes dans la logique que je ne vois pas comme étant bien supportée par le papier. Deuxièmement, il admet qu'il ne mesure que les «sous-parties de la testabilité» et que la «testabilité» en général n'est pas quelque chose de facile à définir. Enfin, leur mesure de testabilité est définie en termes de nombre de dépendances injectées!

• Effets de l'injection de dépendance sur la maintenabilité . Ils comparent les projets utilisant DI aux projets n'utilisant pas DI qu'ils ont trouvés sur SourceForge et voient s'il y a des différences dans les mesures de cohésion. Pour réduire les biais, ils ont jumelé les projets pour qu'ils soient aussi similaires que possible. En fin de compte, ils ont vu des signaux que les projets avec beaucoup d'ID étaient un peu moins couplés que les projets avec seulement peu d'ID. Cependant, il semble qu'il n'y ait pas eu de différence significative de cohésion entre les projets DI et leur paire non DI, donc cela pourrait être une conséquence des domaines spécifiques. Ils listent "aucune corrélation" comme résultat principal et "peut-être que ça aide un peu?" comme sujet à approfondir.

• Évaluation empirique de l'impact de l'injection de dépendance sur le développement d'applications de service Web . Le résumé n'explique pas vraiment ce qu'ils recherchent. J'ai déterré et lu une préimpression et pour autant que je sache, il s'agit en fait de la capacité des outils automatisés à découvrir les services. Les services écrits dans un style DI étaient plus faciles à découvrir. En outre, il cite l'étude précédente que j'ai répertoriée comme fournissant des preuves empiriques que DI réduit le couplage, ce qui est l'opposé de ce que prétendait ce document.

Pour ces trois articles (et pour An Empirical Study into Use of Dependency Injection in Java , qui ne porte que sur la détection), j'ai suivi tous les articles qui les ont cités, dont aucun ne visait à déterminer l'efficacité de l'ID. Compte tenu de tout cela, je suis sûr de dire que non , nous n'avons pas encore de preuves empiriques sur l'amélioration ou non de la qualité logicielle.