【総合】PHPフレームワークを語るスレ8

【総合】PHPフレーム� ..

■コピペモード
□スレを通常表示
□オプションモード
□このｽﾚｯﾄﾞのURL
■項目テキスト

879:nobodyさん
 07/12/04 19:29:14 
自分が分からない話題が続くとイライラしちゃうんじゃないの？たぶん。 
気にすることないよ。

880:nobodyさん
 07/12/04 19:47:46 
>>878 
AOPについではどうだろうか。 
JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。 
というか、AOPなしだとDIのメリットは半減する。 
 
・PHPでもAOPは有効か？（どんなときに？） 
・PHPではAOPも簡単に実現できるか？（YESなら大掛かりな仕組みはいらない）

881:877
 07/12/04 20:39:47 
いや俺はDIいらないでおk。スクリプト言語にはナンセンスで。 
てかjavaでもいいや。xmlに書くとかもうウンザリ。 
コード読んだ方がどこで何やってるかわかりやすいわ。 
他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。 
だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。

882:nobodyさん
 07/12/05 01:58:35 
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のメリットはこんな感じだった。 
 
スクリプト言語でも十分使えると思う。管理という面においては。

次ページ