がるさんとこより
DIコンテナって？
http://d.hatena.ne.jp/gallu/20060822/p2
がるさんも触れてるように一枚はさんで抽象化ってのがキモですね。
私もあまり詳しいわけではないので私なりの理解で書きます。
設計の原則で結合は疎なほうが望ましい。クラスへの依存より抽象(Interface)への依存のほうが望ましいというのに異論はないと思うのですがこの抽象への依存であるという前提に加えて実装への依存を設定ファイルに持っていったもの(newをファクトリメソッドに委譲する)といえます。こうすることによってどういうメリットが生まれるかというとありきたりなところではテストのときにモックを使えるだとかの話になるわけです。どちらかというとモックを使えるというよりはモックでのテスト後にテスト完了したコードに手を入れる必要が無くなると言うのが大きなメリットだと思います。
Interfaceは変えれないので設計時の失敗の塗りつぶしには逆に使えませんし･･･。設定ファイルという気持ち悪さは確かにありますがこれはDIコンテナの設計しだいで違う手法もつかえます。
たとえば.NETなら
namespace Client.Process
{
[ControlManagerEntry]
class PartsAssignDocumentProcess : Client.LayerBase.UIProcessBase, Client.Interface.IPartsAssignDocumentProcess
{
}
}
見たいに属性をぶら下げておいてアセンブリを読みながらインタフェース<->実装のテーブルを起動時に生成するといった方法も使えます。(というか使ってます)
フレームワークの提供側としてみた場合に切り分け方でInterface依存を強制できるというのも見逃せないメリットです。
うまく伝わるかなぁ･･･。