依存性注入を使用すると、ソフトウェアエンジニアリングの成果が向上するという証拠はありますか？

その人気にもかかわらず、依存性注入（および/またはDIコンテナーの使用）が、バグ数の削減、保守性の向上、または実際のソフトウェアプロジェクトの開発速度の向上に役立つことを示す経験的証拠はありますか？

TLDR

経験的データは無関係です。ツールやプラクティス（DIなど）は特定の問題を解決します。、あなたの問題を理解するツールを使用する方法を学び、そしてツールが貴重であるとき、それが明らかになるでしょう- と、あなたははるかに予言任意の一般化、集約、実証的なデータよりも成果を説明できるようになります。

そして今、はるかに冗長に...

実証的な証拠はありますか？

確かに、おそらく。または少なくとも多分。しかし、誰が気にしますか？関係ありません。

DIの統計的費用便益分析は学術的に興味深いかもしれませんが、必ずしも個々の成功を予測するわけではありません。集計結果は、個々の成功と失敗を隠します。そして、「福音主義的」実践に関するデータは特に有毒であると主張するかもしれません。これらの規律は、「純粋な」実装の最終的な影響を不明瞭どちらも両方の狂信者と愚か者を、誘致する傾向があり、どちらかあなたは可能性があるのも！

それで、依存性注入がまったく価値があることをどのように知ることができますか？

良い質問！実際、素晴らしい質問です。そして、私はあなたと一緒です-誰も正当化できない独断的な「ベストプラクティス」に時間と精神的な労力を浪費するのは嫌です。だから、あなたが尋ねてくれてうれしいです。

あー しかし、ここに恥ずかしい問題があります... 一般的に言えば、あなたは知りません。さらに恥ずかしいことに、DIを導入してもコードが実際には改善されない場合があります。

ガス！

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

...

だから、たぶん今あなたは疑問に思っています...

なぜ私は「ナチスのことを証明していない」ことを気にする必要があります！？

まず第一に、議論のあらゆる側面で、すべて落ち着いてみましょう。独断主義と懐疑主義の間には、理性と冷静さの美しい楽園があることを保証できます。（そして時折風変わりなSE.SEポスト。）そして、POAPはそこにあなたを導くことができます。

...つまり、原則を適用する原則：

原則、パターン、および慣行は最終目的ではありません。したがって、それぞれの適切で適切なアプリケーションは、より優れた、より最終的な目的に触発され、制約されます。

あなたがしていることをしている理由を理解する必要があります！

（POAPはPOAPから免除されません。）

^{（「エンファシス鉱山」と言いますが、とにかく私自身の「ブログ」からです。だから、それはすべて私のものです！）}

繰り返しになりますが、あなたは自分がやっていることをしている理由を理解する必要があります。

そして、おそらく明確にするために、通常、特定の「何か」（依存性注入など）を取り、それが解決する問題をまだ理解せずに使用することは意味がありません- あなたのために。問題と「DI」などの「何か」がどのように機能するかを理解すれば、一般化され、集約された経験的データが示唆するものに関係なく、「何か」がどれほど役立つかが「明らか」になります。

あなたのDIの有用性または非有用性が明らかでない場合、または少なくともあなたの推論力を超えている場合、DIを理解していないか、自分の問題を理解していないかのどちらかです。

実世界の「たとえ」を考えてみましょう。

ボックスを作成する必要があります。木があります。爪があります。また、2つのツールがあります。標準の爪ハンマーとドライバーです。

さて、ドライバーで構成されたボックスは、ハンマーで構成されたボックスと比較して、全体的に非常に堅牢なボックスであることを示すいくつかの広範な経験的データがあるかもしれません。しかし、それらの釘をねじ込もうとしても、箱はまったくありません。そして、ドライバーでそれらを叩き込もうとすると、最終的にそれらを取得する可能性があります。しかし、それは非常に多くの時間と労力を必要とし、最終結果は単純にハンマーを使用した場合よりも精度が低くなります（そして堅牢になります）。

そして、誰かが以前にいずれかのツールを使用するのを見たことがあり、ボックスがどのように見えるかを理解していれば、決定は明白です。

テレキネシス！

エラー...うーん...

ええ、それでは、依存性注入はどのような問題を解決しますか？

これは、多くの場合テストできない、厳格で構成不可能なコードを防ぐ働きをします。

これは、モジュールを操作するオブジェクトを決定するための呼び出しコードを許可することによりこれを行います。そして、私はあなたがそれを考えていることを知っています、そしてあなたは正しいです：これはリモートの新しい概念でさえありません。代数が発生してからメソッド/関数パラメーターが存在しました。

不均衡を確認するのに十分なコードを蓄積して継承した後、基本的なパラメーターの受け渡しを「依存性注入」と呼び始めました。依存関係が隠されていたという理由だけで、上に座っていた山のコードは簡単に変更、テスト、または再利用することさえできませんでした。

したがって、依存性注入の熱心な十字軍...

K.しかし、私は引数をうまく渡すことができます。なぜフレームワークなのか？

私が理解しているように、DI フレームワークは、特に定型的なビルドの問題（熱心なDI、IMOによる）を解決します。特に、それらを必要とするすべてのモジュールに標準の「デフォルト」依存関係がある場合です。DIフレームワークは、呼び出しの時点で明示的に渡されない場合に、これらのデフォルトの依存関係を回避するために、魔法の（場合によってはいたずらな！）ことを行います。（この方法で使用した場合、サービスロケーターと同じ効果がありますのでご注意ください！）

「ディシプリン」としての依存性注入は、実際に正しく実行するのが非常に困難です。DIを使用するかどうかは問題ではありません。どの依存関係が変更される可能性が高いか、またはそれらをモックして注入する必要があるかを知ることです。そして、それは、DIがService Locationのような他の選択肢よりも優れているかどうかを決定することの問題です...

しかし、私はあなたにそれをグーグルに奨励し、おそらくこのSOの答えを見て、おそらくあなたの業界で超経験豊かで成功した開発者に話し、特定の例をCR.SEに投稿してください。

Google、Google Scholar、ACM、IEEEを検索しましたここで見つけた論文は次のとおりです。

• 依存性注入フレームワーク：テスト容易性の改善？。「テスト容易性」は「低凝集性」と定義できると主張しています。DIは結束性の低下につながり、結着性の低下はより高いテストカバレッジと相関し、より高いテストカバレッジは発見されたより多くの障害と相関していると述べています。これに基づいて、DIはテスト容易性を改善すると述べています。

  いくつかの理由でこれが好きではありません。まず、「AはBと相関し、BはCと相関しているため、AはCを引き起こします」と言っています。第二に、「テスタビリティの下位部分」を測定するだけであり、一般に「テスタビリティ」は簡単に定義できるものではないことを認めています。最後に、テスト容易性の測定は、注入された依存関係の数に関して定義されます！

• 保守性に対する依存性注入の影響。彼らは、SourceForgeで見つけたDIを使用していないプロジェクトとDIを使用しているプロジェクトを比較し、凝集度メトリックに違いがあるかどうかを確認します。バイアスを減らすために、彼らはプロジェクトを可能な限り類似するように組み合わせました。最終的に、DIが多いプロジェクトは、DIが少ないプロジェクトよりも結合がやや弱いというシグナルを目にしました。ただし、DIプロジェクトとその非DIペアとの凝集度に大きな違いはなかったため、特定のドメインの結果である可能性があります。彼らは彼らの主要な結果として「相関なし」と「たぶんそれは少し役立つ？」をリストします。さらなる研究のトピックとして。

• Webサービスアプリケーションの開発に対する依存性注入の影響を経験的に評価します。要約では、彼らが探しているものを実際に説明していません。プレプリントを掘り下げて読みましたが、実際には、自動化されたツールがサービスをどれだけ発見できるかがわかります。DIスタイルで記述されたサービスはより簡単に発見されました。また、DIがカップリングを減少させるという経験的証拠を提供するものとして私がリストした以前の研究を引用しているが、これはその論文が主張したものの反対である。

これら3つの論文（および検出に関するJavaの依存性注入の使用に関する実証的研究）については、それらを引用したすべての論文をフォローアップしましたが、いずれもDIの有効性を決定するものではありませんでした。以上のことを考えると、「いいえ」と言って自信があります。DIがソフトウェアの品質を改善するかどうかについての経験的証拠はまだありません。