DIってなによ

C#2.0 EntLib2.0 ObjectBuilder DI

特集：Enterprise Library 2.0新機能
Enterprise Library 2.0を特徴づけるDI機能とは
http://www.atmarkit.co.jp/fdotnet/entlib/entlibv2/entlibv2_03.html
のサンプルコードで、

this._targetClass.SetValue("ConcreateTargetClassを生成");

とあるが、コンパイルエラーになる。this._targetObjectの間違いだろう。

あとDIの前提知識が不足しているのか、先のページを見てもいまいちピンとこない。
DI関連のページをいろいろあさってみるが、大抵のページで説明されている以下の文章でつまずいて、後の文章が理解できない。

コンポーネント間の依存性を排除

これが、何を指しているかが不明(^^;
まぁ、そこがわからなくても、これを実現したことによるメリットがわかればわかった気になれそうだ。

higaさんによるダイコン時代の設計方法(URL)を読んでみる。

メリットはDependency Injectionパターンが詳しい。

１．コンポーネント同士は、インターフェースを通じてのみ会話するようにする。

プログラムの呼び出し方（インターフェース）をインターフェースとして定義する。
呼び出し元（コンポーネント）は、このインターフェースを呼ぶことで処理を実行する。
呼び出し先（コンポーネント）は、このインターフェースで呼ばれることを前提に作られている。
結果、同じインターフェースを持っていれば、呼び出し先の切り替えができる。
この際、呼び出し元を変更しなくても良いのがメリット。

具体的な場面で言うと

・モックオブジェクトに差し替えてテストを簡単におこなえるようになる。 
・実装がなくても、モックオブジェクトを使って開発が進められるため、実装待ちの無駄な時間をカットできる。

ということになる。
なんとなく、やりたいことが見えてきました。

で、次の疑問点。
共通のインターフェースを持ち、複数のプログラムを切り替えるという面から考えると、プラグインも同様ではないか。プラグインとどう違うの？

これが２．と書いてある部分かな。

２．コンポーネントの生成や、依存関係の解決は、コンテナがおこなう。

XMLファイルなんかで使用するコンポーネントの名前を与えると、コンテナが該当するコンポーネントを生成して返してくれる。って感じかな。
プラグインだと、同じインターフェースのコンポーネントがあったら全部取り込めるけど、どれか一つを選択して起動するような用途には使えない。これを外部設定ファイルから指定してやるのがDIコンテナということか。

ただ、DIにインターフェースは必須かを見ると、インターフェースなしでも生成できるような話もあって、ここで理解がつまづいた。
結局、インターフェースを全部記述するのも手間がかかるよねって話なんだろうけど、インターフェースなしだと、呼び出し元は、どこから呼び出し先の使い方を知るのだろう？？？

その他、気になる文章をメモ

・個々の開発者に例外をcatchさせるとろくなことにならないというのが、私の経験則。(URL)

これは心に刻んでおいた方がよさそうだ。