によるマーティン・ファウラーが書いた論文制御の反転とは、プログラムの制御フローが反転される原理です。つまり、プログラマがプログラム フローを制御するのではなく、外部ソース (フレームワーク、サービス、その他のコンポーネント) が制御します。何かを別の何かに接続するようなものです。彼は EJB 2.0 の例を挙げました。
たとえば、セッション Bean インターフェイスは、ejbRemove、ejbPassivate (二次ストレージに保存)、および ejbActivate (パッシブ状態から復元) を定義します。これらのメソッドが呼び出されるタイミングは制御できませんが、その内容は制御できます。コンテナーが呼び出します。私たちが呼び出すわけではありません。
これにより、フレームワークとライブラリの違いが生まれます。
制御の反転は、フレームワークとライブラリを区別する重要な要素です。ライブラリは基本的に、呼び出すことができる関数のセットであり、最近ではクラスに編成されるのが一般的です。各呼び出しは何らかの作業を実行し、クライアントに制御を返します。
DI が IOC であるという観点は、オブジェクトの依存関係が逆転していることを意味します。つまり、オブジェクト自体の依存関係やライフサイクルを制御するのではなく、他の何かがそれを実行します。ただし、手動による DI についておっしゃったように、DI は必ずしも IOC ではありません。DI があっても IOC がなくてもかまいません。
ただし、この論文 (C/C++ 用の別の IOC フレームワークである pococapsule より) では、IOC と DI のおかげで、IOC コンテナーと DI フレームワークは J2EE よりもはるかに優れていると示唆されています。これは、J2EE がフレームワーク コードをコンポーネントに混合し、Plain Old Java/C++ Object (POJO/POCO) にならないためです。
依存性注入パターン以外の制御コンテナの反転（アーカイブリンク）
古いコンポーネントベースの開発フレームワークの問題点を理解するための追加の資料は、上記の 2 番目の論文につながります。制御の反転の理由と内容（アーカイブリンク）
質問: IOC と DI とは正確には何ですか? 混乱しています。pococapsule によると、IOC はオブジェクト間またはプログラマとフレームワーク間の制御の単なる反転よりも重要なものです。
ベストアンサー1
Inversion-of-Control (IoC)パターン は、自分自身で直接操作するのではなく (言い換えると、制御を反転したり外部ハンドラー/コントローラーにリダイレクトしたり)、反応を「実装」および/または制御するあらゆる種類 の を提供 callbackすることです。
たとえば、アプリケーションがライブラリ(ツールキットとも呼ばれます) によって提供される実装を呼び出すのではなく、ライブラリやフレームワークがアプリケーションによって提供される実装を呼び出します。
Dependency-Injection (DI)パターン は IoC パターンのより具体的なバージョンであり、実装はコンストラクター/セッター/サービス ルックアップを通じてオブジェクトに渡され、オブジェクトは正しく動作するためにこれに「依存」します。
すべての
DI実装は とみなすことができますIoCが、 と呼ぶべきではありませんIoC。依存性注入の実装はコールバックよりも難しいからです (代わりに一般的な用語「IoC」を使用して製品の価値を下げないでください)。
たとえば、DI を使用しない IoC は、実装がサブクラス化を通じてのみ変更できるため、テンプレート パターンになります。
DI フレームワークはDI を利用するように設計されており、実装を簡単に渡すためにインターフェース (または Java のアノテーション) を定義できます。
IoCコンテナは、プログラミング言語の外で機能するDIフレームワークです。いくつかのコンテナでは、メタデータファイル（XMLなど）で、使用する実装を構成できるため、侵襲性が低くなります。いくつかのコンテナでは、通常では不可能なIoC、たとえば、実装を注入するなどを行うことができます。ポイントカット。
こちらもご覧くださいマーティン・ファウラーの記事。