DI IoC

http://0xcc.net/blog/archives/000172.html

なるほどなるほど。DI(Dependency Injection)とIoC(Inversion of Control)の関係がやっと理解できた。
IoCって、フレームワークで使われている、コールバックを使った穴埋め式の実装方法
のことだったのね。
IoCに関しては、以下の説明がわかりやすい。

ここで疑問なのは、軽量コンテナは制御のどういった側面を反転させているのか、ということだ。私がはじめて制御の反転というものに遭遇したとき、それはユーザインタフェースのメインループのことだった。初期のユーザインターフェースは、アプリケーションプログラムで制御されていた。「名前の入力」「住所の入力」みたいな一連のコマンドを取り扱いたいとなれば、プログラムでプロンプトの表示と、それぞれの入力を制御する。これがグラフィカルなUI(コンソールベースでもいいけど)になると、UIフレームワークにはメインループがあり、フレームワークからスクリーンの様ざまなフィールドの代わりとしてイベントハンドラが提供されている。プログラムではこのイベントハンドラを取り扱う。ここではプログラムの中心となる制御が反転されている。制御は個々のプログラムからフレームワークへと移されているのだ。

そいでもって、DIだけがサービスの設定とサービスの使用方法を分離する方法じゃないよと。
Service Locator を使用するもあるよと。Service Locatorを使うと、DIを使うより制御の主体がアプリケーションにあるので、デバッグしやすい。
IoCは依存関係をきれいに分離できるが、コールバックを使うのでブラックボックスのフレームワーク内を処理が通過してくるのでたしかにデバッグがしづらい。
どちらの実装を使うかを決める判断基準は、ロケータを探し出す処理を書かなければならないかどうか。

この文書に所々リンクされている↓本の説明がなんかスバラシイ。読みたくなった。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

Plgin

http://martinfowler.com/eaaCatalog/plugin.html

Links classes during configuration rather than compilation.
(コンパイルではなく、設定によるクラスのリンクを行う)

まさに。Pluginを一般化するとそういう説明になるのかと。