DIについて俺の経験を書いてもいい？

以前開発していたちょっと中規模なプロジェクトがあったんだけど、
そのプロジェクトはDIコンテナのような仕組みが無くて、
>>847の書いたようなファクトリモドキを書いて、開発してたんだよ。

で、プロジェクトも終盤になってよし結合テストしよう！ってなったときに、
みんながcommon.phpみたいな必ず読み込まれるようなファイルに
$hoge = 'MyClass'
みたいな記述をして、どこからrequireされたか分からない、autoloadされたクラス内で
$obj = new $hoge($params)
と書かれてたんだわ。
それ自体は別に共通化されたファイル内に書かれていたから良かったんだけど、ときどきデバッグ用に
$hoge = 'OtherClass'
とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。
あと、依存関係が全然整理されてなくて
public function __construct($str){
　　$this->hoge = new $str;
}
なんて記述があったときには、何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。（ドキュメントがあまり書かれてなかったんだよね...)

それがあってから、俺が担当するプロジェクトはDIを使うようにしてる。
どこで生成されるべきか、どこで使うか、どうやって切り替えるかを明確にするためにDI使ってる。

設定ファイルの管理は面倒だけど、テストがその分、楽になったかな。
DIのメリットはこんな感じだった。

スクリプト言語でも十分使えると思う。管理という面においては。