依存性注入の使用がソフトウェア工学の結果を改善するという証拠はありますか？
その人気にもかかわらず、依存性注入（および/またはDIコンテナーの使用）が、たとえばバグ数の削減、保守性の向上、または実際のソフトウェアプロジェクトの開発速度の向上に役立つことを示す経験的証拠はありますか？
TLDR
経験的データは無関係です。ツールやプラクティス（DIなど）は、particularの問題を解決します。問題を理解し、ツールの使用方法を学ぶと、ツールの価値が明らかになります-and結果をより詳しく説明できるようになります一般化された集計された経験的データよりも予言的に。
そして今、より多くの冗長性で...
実証的な証拠はありますか？
はい、たぶん。または、少なくとも多分。しかし、誰が気にしますか？ 関係ありません。
DIの統計的費用便益分析は学問的に興味深いかもしれませんが、個人の成功を必ずしも予測するものではありません。集計結果は個々の成功および失敗を隠します。そして、「福音主義的」実践に関するデータは特に有毒であると主張するかもしれません。これらの規律は、狂信者と愚か者の両方を引き付ける傾向があり、どちらも「純粋な」実装の正味の影響を覆い隠し、どちらかそれらのうち、be！
それでは、依存性注入が価値があることをどのようにして知ることができますかまったく？
良い質問！実際、すばらしい質問です。そして、私はあなたと一緒にいます-私は、誰も正当化できない独断的な「ベストプラクティス」に時間と精神的な労力を費やすことを嫌います。それで、あなたが尋ねてうれしいです。
うーん。しかし、ここに恥ずかしい問題があります...generalで、あなたしないでください知っています。そして、さらに恥ずかしいことに、DIを導入しても、コードが実際には改善されない可能性があります。
GASP！
⊙▃⊙ . . . (╯°□°)╯︵ ┻━┻
...
だから、多分今あなたは疑問に思っています...
なぜ私は「物事はヌチンが証明されていない」ことに悩む必要があります！？
まず第一に、すべてのことを-議論のあらゆる面で-ただ落ち着いてみましょう。独断主義と懐疑論の間に、理性と平凡さの美しい楽園があることを私はあなたに保証することができます。 （そして、時折風変わりなSE.SEの投稿。）そして、POAPはあなたをそこに導くことができます。
...つまり、 適用原則の原則 ：
原則、パターン、および実践は最終的な目的ではありません。したがって、それぞれの適切で適切なアプリケーションは、より優れた、より最終的な目的によって刺激され、制約されます。
あなたはあなたが何をしているのかを理解する必要があります！
（POAPはPOAPから免除されません。）
（私は「強調」と言いますが、とにかく自分の「ブログ」からです。つまり、allです！）
ここで要点を繰り返します。なぜあなたが今していることをしているのかを理解する必要があります。
そしておそらく明確にするために、特定の「何か」（Dependency Injectionなど）を取り、それが解決する問題-を具体的に理解していない状態で使用することは通常意味がありません。 問題と「何か」（DIなど）がどのように機能するかを理解していれば、「何か」の有用性はいくぶん「明白」であり、一般化されたものに関係なく、集計された経験的なデータが示唆しています。
DIの有用性またはun-有用性が明らかでない場合、または少なくとも推論力を超えている場合、DIを理解していないか、または理解していないあなた自身の問題を理解してください。
現実世界の「寓話」について考えてみましょう。
ボックスを作成する必要があります。木があります。爪があります。また、 標準の爪ハンマー と ドライバー の2つのツールがあります。
現在、ドライバーで構築されたボックスは、ハンマーで構築されたボックスと比較して、全体的にはるかに堅牢なボックスであることを示すいくつかの広範な経験的データがあるかもしれません。しかし、それらの釘をねじ込もうとすると、箱がまったくなくなることはありません。そして、ドライバーでそれらを叩き込もうとすると、結局それらを中に入れるかもしれません。しかし、それはかなり多くの時間と労力を必要とし、最終的な結果は単にハンマーを使用した場合よりも正確ではありません（そして堅牢です）。
また、誰かが以前にいずれかのツールを使用するのを見たことがあり、ボックスがどのように見えるかを理解している場合、決定は明白です。
テレキネシス！
えっと…うーん….
ええ、それでは、依存性注入はどのような問題を解決しますか？
堅固で構成できないコードを防ぐために機能します。そのため、多くの場合、コードはun-testableになります。
これは、invokingコードに、モジュールが操作するオブジェクトを決定することを許可することによって行われます。そして、私はあなたがそれを考えていることを知っています、そしてあなたは正しいです：これは遠く新しい概念でもありません。代数が発生して以来、メソッド/関数パラメーターが存在しています。
不均衡を確認するのに十分なコードを蓄積して継承したら、基本的なパラメーターの受け渡しを「依存性注入」と呼び始めました。依存関係が隠されていたからといって、上に置かれていたコードの山は、簡単に変更したり、テストしたり、さらにはreusedすることさえできませんでした。
したがって、依存性注入のための熱心な十字軍...
K.しかし、私は引数を問題なく渡すことができます。なぜframeworks？
私が理解しているように、DIframeworksは主にボイラープレートビルドアップの問題を解決します（過度のDI、IMOによる）-特にすべてのモジュールに標準の「デフォルト」の依存関係がある場合それらを必要とします。 DIフレームワークは、呼び出し時に明示的に渡されない場合に、これらのデフォルトの依存関係をすり抜けるための魔法の（潜在的にいたずらなことさえ！）ことを行います。 （この方法で使用した場合、 Service Locator と同じ効果があります。ご注意ください。）
「規律」としての依存性注入は、実際に正しく実行するのが非常に困難です。 DIを使用するかどうかは問題ではありません。どの依存関係が変更される可能性が高いか、またはモックとインジェクションが必要なthoseを知ることです。次に、サービスロケーションなど、DIがいくつかの代替策よりも適しているかどうかを判断することが重要です...
しかし、 Google it 、多分 this SO answer を参照することをお勧めします。おそらく、経験豊富で成功した開発者と話してください。あなたの業界で、具体的な例を CR.SE に投稿してください。
私はGoogle、Google Scholar、ACM、IEEEを検索しました。ここで私が見つけた論文は次のとおりです。
依存性注入フレームワーク：テスト容易性の改善？ 。 「テスト容易性」は「凝集性が低い」と定義できると主張している。それは、DIが凝集度の低下につながり、凝集度が低いほどテストカバレッジが高くなること、テストカバレッジが高いほど検出される障害の数が増えることを示しています。これに基づいて、DIはテスト容易性を向上させると述べています。
いくつかの理由でこれは好きではありません。まず、「AはBと相関し、BはCと相関しているので、AはCを引き起こす」と言っています。これは、私がこの論文で十分にサポートされているとは思えないロジックのいくつかのステップです。第二に、それは「テスト容易性のサブパート」を測定するだけであり、一般に「テスト可能性」は簡単に定義されるものではないことを認めています。最後に、テスト可能性の測定は、注入された依存関係の数によって定義されます。
メンテナンス性に対する依存性注入の影響 。彼らは、DIを使用するプロジェクトをSourceForgeで見つけたDIを使用しないプロジェクトと比較し、凝集度メトリックに違いがあるかどうかを確認します。偏見を減らすため、彼らはプロジェクトを可能な限り類似させるためにペアを組んだ。最終的に、DIが多いプロジェクトは、DIが少ないプロジェクトよりも結合がやや弱いというシグナルが出ました。ただし、DIプロジェクトとそれらの非DIペアとの間の結束に有意差はなかったようで、特定のドメインの結果である可能性があります。彼らは主な結果として「相関関係なし」をリストし、「多分それは少し助けになるでしょうか？」さらなる研究のためのトピックとして。
Webサービスアプリケーションの開発に対する依存性注入の影響を経験的に評価する 。アブストラクトは、彼らが何を求めているかを実際に説明するものではありません。私はプレプリントを掘り下げて読みましたが、私が知る限り、自動化されたツールがサービスをどれだけうまく検出できるかについて実際にわかっています。 DIスタイルで記述されたサービスは、より簡単に発見されました。また、私が挙げた以前の研究は、DIがカップリングを低減するという実証的な証拠を提供していると引用しています。これは、その論文の主張とは逆です。
これらの3つの論文（および Javaでの依存性注入の使用に関する実証的研究 、これは検出のみに関するもの）について、それらを引用するすべての論文をフォローアップしましたが、どれも有効性の決定に関するものではありませんでした。 DIの。これらすべてを踏まえると、noと言っても、DIがソフトウェア品質を向上させるかどうかについての実証的な証拠はまだありません。