私は IoC と DI について多くのことを読みましたが、ほとんどの状況でそれらを使用することで多くの利益が得られるとは確信していません。
プラグ可能なコンポーネントを必要とするコードを作成している場合、その価値はわかります。しかし、そうでない場合は、依存関係をクラスからインターフェイスに変更することで、タイピングの増加以外に本当に何かが得られるかどうか疑問に思います。
場合によっては、IoC と DI がどこでモッキングに役立つかがわかりますが、モッキングや TDD を使用していない場合、どのような価値があるのでしょうか? これはYAGNIのケースですか？
確かなデータがあるとは思えないので、いくつかの考えを追加します。
まず、DI (またはその他の SOLID 原則) を使用しないのは、TDD を実行するのに役立つからです。逆に、TDD を使用するのは設計に役立つためです。これは通常、これらの原則に従うコードを取得することを意味します。
インターフェイスを使用する理由については別の問題です。 https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfacesを参照してください。
クラスに多くの異なることをさせると、コードが乱雑になることに同意していただけると思います。したがって、私はあなたがすでに SRP に取り組んでいると仮定しています。
特定のことを行うさまざまなクラスがあるため、それらを関連付ける方法が必要です。それらをクラス (つまり、コンストラクター) 内で関連付けると、特定のバージョンのクラスを使用する多くのコードが得られます。これは、システムに変更を加えることが困難になることを意味します。
システムを変更する必要があります。これはソフトウェア開発の事実です。特定の余分な機能を追加しないことについて YAGNI に電話することはできますが、システムを変更する必要がないということについては電話できません。私の場合、毎週スプリントを行っているので、これは非常に重要なことです。
コードを使用して構成を行う DI フレームワークを使用しています。非常に小さなコード構成で、多くの異なるリレーションを接続します。したがって、インターフェイスと具象クラスの議論を取り除けば、実際には入力を節約できますが、その逆ではありません。また、具体的なクラスがコンストラクターにある場合は、それを自動的にフックして (構成する必要はありません)、残りの関係を構築します。また、一部のオブジェクトのライフタイムを制御することもできます。特に、オブジェクトをシングルトンとして構成し、常に単一のインスタンスを渡すことができます。
また、これらのプラクティスを使用するだけでは、オーバーヘッドが増えるわけではないことに注意してください。それらを初めて使用することがオーバーヘッドの原因です (学習プロセス + 場合によってはマインドセットの変化のため)。
結論: 高速化するために、コンストラクター呼び出しをあちこちに配置する必要はありません。
DIからの最も重要な利点は、必ずしもインターフェイスの使用によるものではありません。依存性注入の有益な効果を得るために、実際にインターフェースを使用する必要はありません。実装が1つしかない場合は、おそらくそれを直接注入でき、クラスとインターフェイスを組み合わせて使用できます。
まだ結合が緩んでおり、必要に応じて数回キーを押すだけでそのインターフェイスを導入できる開発環境がかなりあります。
緩い結合の価値に関する確かなデータは私には言えませんが、私が覚えている限り、それは教科書のビジョンでした。今では本物です。
DIフレームワークは、大規模な構造の階層構造に関しても、非常に優れた機能を提供します。最もスリムなDIフレームワークを探す代わりに、フル機能のDIフレームワークを探すことをお勧めします。少なくともプログラミングの新しい方法について学ぶことになると、少ないことが常に多いとは限りません。その後、あなたはより少ない費用で行くことができます。
テストとは別に、疎結合も価値があります。
私は、組み込み Java システムのコンポーネントに取り組んできました。これは、起動後のオブジェクトの構成が固定されていました (約 50 の異なるオブジェクト)。
最初のコンポーネントは、依存性注入のないレガシー コードであり、サブオブジェクトがいたるところに作成されていました。現在、いくつかの変更のために、コンストラクターが 3 つしか離れていないオブジェクトと対話する必要があるコードが何度か発生しました。では、別のパラメーターをコンストラクターに追加して渡すか、フィールドに格納して後で渡す以外に何ができるでしょうか。長期的には、物事は以前よりもさらに複雑になりました。
ゼロから開発した 2 番目のコンポーネントで、依存性注入を使用しました (当時は知らなかった)。つまり、すべてのオブジェクトを構築し、必要に応じて注入する 1 つのファクトリがありました。別の依存関係を追加するのは簡単で、ファクトリとオブジェクト コンストラクターに追加するだけです (または、ループを回避するためにセッターを追加します)。関係のないコードに手を加える必要はありません。