依存性注入に関するこのコースのビデオを見ていますが、講師はそれについて話していましたdi-containerが、詳細には説明していませんでした。今、いくつかの記事を読んで、これが正しいことを確認したいと思っています。以下は簡単なプログラムですが、私の質問は、
以下のプログラムクラスは最も単純なdi-containerの一種でしょうか？そうでない場合、単純なdi-containerはどのようになるでしょうか？
interface Implementable {
void doSmth();
}
class A implements Implementable {
@Override
public void doSmth() {
}
}
class B {
private Implementable i;
public B(Implementable implementable) {
this.i= implementable;
}
public void doSmth(){
i.doSmth();
}
}
このクラスは di-container ですか?
class Program {
B b = new B(new A());
b.doSmth();
}
ベストアンサー1
によると依存性注入の原則、実践、パターンDI コンテナとは、次のものです。
「DI機能を提供し、多くのタスクを自動化できるソフトウェアライブラリ。オブジェクトの構成、傍受、 そしてライフタイムマネジメント。DI コンテナ制御の反転 (IoC) コンテナーとも呼ばれます。（§3.2.2）
少なくとも、DI コンテナーでは自動配線が可能になります。
「マップからオブジェクトグラフを自動的に作成する機能抽象化コンパイラと[そのランタイム環境]によって提供される型のメタデータを利用することで、具体的な型を作成できます。（§12.1.2）
これは通常、DI コンテナーが型のコンストラクターを分析し、各コンストラクター引数を手動で指定する必要なく、そこに依存関係を注入することを意味します。
その観点からすると、あなたのProgramクラスはないDIコンテナですが、Programクラスはコンポジションルートの一部であるコンポーザーとして機能します。構成ルートは：
「モジュールが一緒に構成されているアプリケーション内の (できれば) 一意の場所です。（§4.1）
Composer は、オブジェクト グラフの実際の構築を行う Composition Root の一部です。
「それは重要な部分です構成ルート。作曲多くの場合、DIコンテナただし、手動でオブジェクトグラフを構築する任意の方法でもよい。（§8）
特定のコンポジションルートでは、DIコンテナを使用する代わりに、ピュアDIつまり、
「DI コンテナなしで DI を適用する方法。（§1.1.1）
new言い換えると、Pure DI は、クラスが示すとおり、DI コンテナーを使用するのではなく、言語のキーワードを使用して手動でオブジェクト グラフを作成する方法ですProgram。
シンプルなdi-containerはどのように見えるでしょうか
DI コンテナの実装は、通常、かなり複雑で、構築方法も多数あります。ただし、その本質は、抽象化と具体的な型の間のマップにあります。このため、ほとんどの DI コンテナは、内部的に辞書またはハッシュ マップを使用します。このStack Overflowの回答わずか数行のコードで、単純な辞書ベースの実装 (C# を使用) を示します。