Gibt es Belege dafür, dass die Verwendung von Dependency Injection die Ergebnisse im Software-Engineering verbessert?

Gibt es trotz seiner Beliebtheit empirische Belege dafür, dass Dependency Injection (und / oder die Verwendung eines DI-Containers) beispielsweise bei der Reduzierung der Fehleranzahl, der Verbesserung der Wartbarkeit oder der Erhöhung der Entwicklungsgeschwindigkeit bei echten Softwareprojekten hilft?

TLDR

Die empirischen Daten sind irrelevant. Tools und Methoden (wie DI) lösen bestimmte Probleme. Verstehen Sie Ihre Probleme, lernen Sie den Umgang mit den Werkzeugen und es wird deutlich, wann ein Werkzeug wertvoll ist - und Sie können die Ergebnisse prophetischer erklären als alle verallgemeinerten, aggregierten, empirischen Daten.

Und jetzt mit viel mehr Ausführlichkeit ...

Gibt es empirische Beweise?

Sicher wahrscheinlich. Oder zumindest vielleicht. Aber wen interessiert es? Es ist nicht relevant.

Eine statistische Kosten-Nutzen-Analyse von DI mag wissenschaftlich interessant sein, sagt jedoch nicht unbedingt den individuellen Erfolg voraus. Aggregierte Ergebnisse verbergen individuelle Erfolge und Misserfolge. Und ich könnte argumentieren, dass Daten über "evangelische" Praktiken besonders giftig sind. Diese Disziplinen ziehen sowohl Eiferer als auch Narren an, die beide die Nettoauswirkung einer "reinen" Implementierung verschleiern und von denen Sie beide sein könnten !

Woher wissen wir also, dass Abhängigkeitsinjektion überhaupt wertvoll ist ?

Gute Frage! Tatsächlich eine GROSSE Frage. Und ich bin bei Ihnen - ich hasse es, Zeit und Mühe mit dogmatischen "Best Practices" zu verschwenden, die niemand rechtfertigen kann. Ich bin froh, dass Sie gefragt haben.

Uhh. Aber hier ist das peinliche Problem ... Im allgemeinen Begriffen, Sie nicht wissen. Und noch peinlicher ist es, dass Ihr Code durch die Einführung von DI in keiner Weise besser wird.

KEUCHEN!

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

...

Vielleicht fragst du dich jetzt ...

Warum sollte ich mir die Mühe machen, dass Dinge nicht ähm bewiesen sind?

Lassen Sie uns zuallererst einfach - auf jeder Seite der Debatte - zur Ruhe kommen. Ich kann Ihnen versichern, dass zwischen Dogmatismus und Skepsis ein wunderschönes Paradies der Vernunft und Besonnenheit liegt. (Und der gelegentliche exzentrische SE.SE-Beitrag.) Und der POAP kann Sie dorthin führen.

... Womit ich meine, das Prinzip der Anwendung von Prinzipien :

Prinzipien, Muster und Praktiken sind keine endgültigen Zwecke. Die gute und ordnungsgemäße Anwendung eines jeden wird daher von einem überlegenen, endgültigeren Zweck inspiriert und eingeschränkt .

Sie müssen verstehen, warum Sie das tun, was Sie tun!

(Der POAP ist nicht vom POAP ausgenommen.)

^{(Ich würde sagen, "Hervorhebung meiner", aber es ist auf jeden Fall aus meinem eigenen "Blog". Also, es ist alles meins!)}

Lassen Sie mich den Hauptpunkt wiederholen: Sie müssen verstehen, warum Sie das tun, was Sie tun.

Und vielleicht ist es zur Verdeutlichung in der Regel nicht sinnvoll, ein bestimmtes "Etwas" (wie "Abhängigkeitsinjektion") zu nehmen und es zu verwenden, ohne bereits zu verstehen, welches Problem es löst - speziell für Sie. Wenn Sie Ihre Probleme verstehen und wissen, wie das "Etwas" (wie DI) funktioniert, wird es einigermaßen "offensichtlich" sein, wie hilfreich das "Etwas" ist, unabhängig davon, was die verallgemeinerten, aggregierten, empirischen Daten nahelegen.

Wenn DI des Hilfs oder un -helpfulness Ihnen nicht klar ist - oder zumindest über Ihre Denkfähigkeit - Sie entweder nicht verstehen , DI, oder Sie nicht über Ihre eigenen Probleme verstehen.

Betrachten wir eine reale "Parabel".

Wir müssen eine Kiste bauen. Wir haben Holz. Wir haben Nägel. Und wir haben zwei Werkzeuge: Einen normalen Klauenhammer und einen Schraubendreher .

Nun können wir einige breite empirische Daten haben, um zu zeigen, dass mit Schraubenziehern hergestellte Kästen insgesamt wesentlich robuster sind als mit Hämmern hergestellte. Aber wenn Sie versuchen, diese Nägel einzuschrauben, werden Sie überhaupt keine Schachtel haben. Und wenn Sie versuchen, sie mit dem Schraubenzieher einzuschlagen, können Sie sie möglicherweise einführen. Dies erfordert jedoch erheblich mehr Zeit und Mühe, und das Endergebnis ist weniger präzise (und robuster) als wenn Sie einfach den Hammer verwendet hätten.

Und wenn Sie schon einmal jemanden gesehen haben, der eines der beiden Tools verwendet, und wenn Sie verstehen, wie eine Box aussieht, liegt die Entscheidung auf der Hand.

Telekinese!

Äh ... hmm ...

Ja, welches Problem löst Dependency Injection?

Es verhindert starren, nicht konfigurierbaren Code, der daher oft nicht testbar ist .

Dies geschieht, indem der Aufruf von Code ermöglicht wird, um zu entscheiden, mit welchen Objekten ein Modul arbeitet. Und ich weiß, dass Sie darüber nachdenken, und Sie haben Recht: Dies ist nicht einmal ein entferntes neues Konzept. Methoden- / Funktionsparameter existieren seit dem Auftreten der Algebra.

Wir haben damit begonnen, die grundlegende Parameterübergabe zu evangelisieren und sie "Abhängigkeitsinjektion" zu nennen, sobald wir genug Code gesammelt und geerbt haben, um unsere Ungleichgewichte zu erkennen. Die Berge von Code, auf denen wir saßen, konnten nicht einfach geändert, getestet oder sogar wiederverwendet werden , nur weil die Abhängigkeiten verborgen waren.

Daher der eifrige Kreuzzug für Abhängigkeitsinjektion ...

K. Aber ich kann gut argumentieren. Warum die Frameworks ?

So wie ich es verstehe, lösen DI- Frameworks in erster Linie das Problem des Boilerplate-Aufbaus (aufgrund von übereifrigen DI, IMO) - insbesondere, wenn für alle Module, die diese benötigen, Standardabhängigkeiten vorhanden sind. DI-Frameworks tun magische (möglicherweise sogar böse!) Dinge, um diese Standardabhängigkeiten einzuschleusen, wenn sie beim Aufruf nicht explizit übergeben werden. (Gleicher Effekt wie ein Service Locator, wenn er auf diese Weise verwendet wird!)

Abhängigkeitsinjektion als "Disziplin" ist eigentlich sehr schwer zu erreichen. Es geht nicht darum, DI zu verwenden oder nicht. es ist eine Sache zu wissen , welche Abhängigkeiten wahrscheinlich ändern oder Notwendigkeit spöttischen sind und Injizieren diejenigen . Und dann ist es eine Frage der Entscheidung, ob DI besser als irgendeine Alternative wie Service Location passt ...

Aber ich möchte Sie dazu ermutigen, es zu googeln , diese SO-Antwort zu lesen , möglicherweise mit einem äußerst erfahrenen und erfolgreichen Entwickler in Ihrer Branche zu sprechen und spezifische Beispiele an CR.SE zu senden .

Ich habe nach Google, Google Scholar, ACM und IEEE gesucht.

• Abhängigkeitsinjektions-Frameworks: eine Verbesserung der Testbarkeit? . Es wird argumentiert, dass "Testbarkeit" als "geringe Kohäsion" definiert werden kann. Darin heißt es, dass DI zu einer geringeren Kohäsion führt, dass eine geringere Kohäsion mit einer höheren Testabdeckung korreliert und dass eine höhere Testabdeckung mit mehr gefundenen Fehlern korreliert. Daraus geht hervor, dass DI die Testbarkeit verbessert.

  Ich mag das aus ein paar Gründen nicht. Zuallererst heißt es: "A ist mit B korreliert, B ist mit C korreliert, also verursacht A C", ein paar Schritte in der Logik, die ich nicht als gut durch das Papier unterstützt sehe. Zweitens gibt es zu, dass es nur "Teilbereiche der Testbarkeit" misst und dass "Testbarkeit" im Allgemeinen nicht leicht zu definieren ist. Schließlich wird ihr Testbarkeitsmaß anhand der Anzahl der injizierten Abhängigkeiten definiert!

• Auswirkungen der Abhängigkeitsinjektion auf die Wartbarkeit . Sie vergleichen Projekte, die DI verwenden, mit Projekten, die DI nicht verwenden, die sie in SourceForge gefunden haben, und prüfen, ob es Unterschiede bei den Kohäsionsmetriken gibt. Um die Verzerrung zu verringern, haben sie die Projekte so ähnlich wie möglich gepaart. Letztendlich sahen sie Signale, dass Projekte mit viel DI etwas weniger gekoppelt waren als Projekte mit nur wenig DI. Es scheint jedoch keinen signifikanten Unterschied in der Kohäsion zwischen den DI-Projekten und ihrem Nicht-DI-Paar zu geben, sodass dies eine Konsequenz der spezifischen Domänen sein könnte. Sie führen "keine Korrelation" als primäres Ergebnis an und das "Vielleicht hilft es ein wenig?" als Thema für das weitere Studium.

• Empirische Bewertung der Auswirkungen der Abhängigkeitsinjektion auf die Entwicklung von Webdienstanwendungen . Die Zusammenfassung erklärt nicht wirklich, wonach sie suchen. Ich habe einen Preprint ausgegraben und gelesen und soweit ich das beurteilen kann, geht es darum, wie gut automatisierte Tools Services erkennen können. In einem DI-Stil geschriebene Dienste wurden leichter erkannt. Sie zitiert auch die frühere Studie, die ich als empirischen Beweis dafür angeführt habe, dass DI die Kopplung reduziert, was das Gegenteil von dem ist, was in dieser Veröffentlichung behauptet wurde.

Für diese drei Veröffentlichungen (und für eine empirische Studie zur Verwendung von Dependency Injection in Java , in der es nur um Entdeckung geht) habe ich alle Veröffentlichungen weiterverfolgt, in denen es nicht um die Bestimmung der Wirksamkeit von DI ging. All dies gegeben, ich sagte zuversichtlich , dass keine , nicht noch empirische Evidenz auf uns nicht, ob oder nicht DI Softwarequalität verbessert.