[解決済み] Inversion of ControlとDependency Injectionの比較

質問

によると マーティン・ファウラー著の論文 プログラマがプログラムの流れを制御する代わりに、外部（フレームワーク、サービス、他のコンポーネント）がプログラムの流れを制御するのである。何かを他の何かに差し込むようなイメージです。EJB2.0についての例を挙げていた。

例えば、セッションビーンのインターフェースは はejbRemove、ejbPassivateを定義しています。 (セカンダリストレージに保存)、そして ejbActivate (パッシブからリストア) の状態）。を制御することはできません。 これらのメソッドが呼び出されるのは、単に を行う。コンテナが私たちを呼び出すのであって、私たちは は呼び出さない。

これは、フレームワークとライブラリの違いにつながります。

制御の逆転は、以下の重要な部分です。 フレームワークと異なる点 ライブラリです。ライブラリは基本的に 呼び出すことができる関数のセットです。 最近は通常 クラスがあります。それぞれの呼び出しが何らかの処理を行い は、クライアントに制御を戻します。

DIがIOCであるということは、オブジェクトの依存関係を逆転させるということだと思います。オブジェクトが自分の依存関係やライフサイクルをコントロールする代わりに、他のものがそれを行う。でも、手探りでDIについて教えていただいたように、DIは必ずしもIOCではないんです。DIがあってもIOCがないこともあり得るのです。

しかし、この論文（pococapsule, another IOC Framework for C/C++より）では、IOCとDIのために、IOCコンテナとDIフレームワークは、J2EEよりはるかに優れていると示唆しています。J2EEでは、フレームワークコードをコンポーネントに混ぜるため、Plain Old Java/C++ Object（POJO/ポコ）にはならないのです。

Dependency Injectionパターン以外のInversion of Controlコンテナ (アーカイブリンク)

古いComponent-Based Development Frameworkの何が問題なのかを理解するための追加読み物で、上の2番目の論文につながる。 制御の逆転はなぜ起こるのか、何をするのか (アーカイブリンク)

私の質問 : IOCとDIとは一体何なのでしょうか？混乱しています。ポコカプセルによると、IOCはオブジェクトやプログラマとフレームワークの間の制御を逆転させるだけでなく、もっと重要なものだそうです。

どのように解決するのか？

その  Inversion-of-Control  (IoC)  パターンを提供することです。  あらゆる種類の  の  callback  (を直接操作するのではなく（つまり、反転させたり、外部のハンドラやコントローラに制御を移す）、その反応を実装したり、制御したりするものです。）

例えば、アプリケーションが ライブラリ (として知られている）。 ツールキット ), a フレームワーク は、アプリケーションが提供する実装を呼び出します。

は  Dependency-Injection  (DI)  パターンとは、IoCパターンをより具体的にしたもので、コンストラクタ/セッタ/サービスルックアップを通じて、オブジェクトに実装を渡し、オブジェクトが正しく動作するために「依存」するものである。

すべての DI の実装は、以下のように考えることができます。 IoC と呼ぶべきではありません。 IoC なぜなら、Dependency-Injectionの実装はコールバックよりも難しいからです（一般的な用語であるIoCを使用して、製品の価値を下げないようにしましょう）。

DIを使わないIoC なぜなら、実装はサブクラス化によってのみ変更可能だからです。

DIフレームワーク はDIを利用するために設計されており、実装を簡単に渡せるようにインターフェース（JavaではAnnotation）を定義することができる。

IoCコンテナ は、プログラミング言語の外側で動作することができるDIフレームワークです。 メタデータファイル（XMLなど）で使用する実装を設定できるものもあり、侵襲性が低くなっています。 あるものは、通常では不可能なIoCを行うことができます。 ポイントカット .

こちらもご覧ください Martin Fowlerの記事 .