【総合】PHPフレームワークを語るスレ8
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001nobodyさん
2007/10/17(水) 16:01:41ID:72/gWtt1http://pc11.2ch.net/test/read.cgi/php/1181350116/
0830nobodyさん
2007/12/01(土) 13:57:51ID:???PHPは・・・Zend Studioおねがいしまつ。
0831nobodyさん
2007/12/01(土) 15:08:06ID:???つか、作り方どっかに転がってなかったか?
0832nobodyさん
2007/12/01(土) 18:28:33ID:???0834nobodyさん
2007/12/01(土) 21:18:47ID:???それこそキリないだろ。
0835nobodyさん
2007/12/01(土) 21:43:32ID:sHVEWDE60836ほれ
2007/12/02(日) 00:38:16ID:???0837nobodyさん
2007/12/02(日) 05:30:09ID:???皆さんphpでDIコンテナって使う機会ありますか?
便利そうだなーと思うものの実際使ったことがないので効果のほどがわかりません
どうでしょうか
0838nobodyさん
2007/12/02(日) 07:23:30ID:???あれはJavaのような融通の利かない言語のためにあるもの。
スクリプト言語にはまず必要ない。
config.php:
<?php $class = 'Foo'; ?>
main.php:
<?php $obj = new $class(); ?>
でたいてい間に合う。
ああAOPがあったか。AOPがやりたいなら悪くないかもしれんが、
スクリプト言語ならAOPも簡単にできそうだしなあ。やっぱいらんと思う。
0839nobodyさん
2007/12/02(日) 12:15:27ID:???0840nobodyさん
2007/12/02(日) 12:26:50ID:???0841nobodyさん
2007/12/02(日) 12:45:42ID:???ってか、それMockとか作るたびにソース書き直してそれやってるの?
DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる
インスタンスの管理だけがDIの利点ではないだろう。
もし、それだけなら単なるFactoryつくればおk
AOPについても同様で、既に作成済みのクラスや機能について
処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。
もしかして、ソース管理は自分一人でやってないよな?
0842nobodyさん
2007/12/02(日) 13:45:47ID:???>ってか、それMockとか作るたびにソース書き直してそれやってるの?
そうだよ。変更箇所だけを集めたファイル(config.php)を作って、必要があれば都度書き換えてる。
DIコンテナも設定ファイルを書き換えるよね。そのXMLファイルがPHPファイルになっただけ。本質的な違いはない。
>DIコンテナはやっぱりテストする際に、実装しているクラスとMockを簡単に切り替える点にあるといえる
>
>インスタンスの管理だけがDIの利点ではないだろう。
>もし、それだけなら単なるFactoryつくればおk
「実装しているクラスとMockを簡単に切り替える」のは「インスタンスの管理」だと思うんだが違うのかね。
ついでにいうと>>838のコードは「実装しているクラスとMockを簡単に切り替え」ている例だと思うけど。何が不満なのかしら。
>AOPについても同様で、既に作成済みのクラスや機能について
>処理を追加したいと考えた際にAOPが無くちゃ何も出来ない。
>誰かがソースを直して待つしかないなら、AOPで書き換えるようにする。
それはJavaにそういう機能がないだけだよね。クラスの定義自体を動的に行うスクリプト言語にそんなこといわれてもなあ。
>もしかして、ソース管理は自分一人でやってないよな?
人数は関係ないんじゃない?Javaではソース管理が一人だとDIコンテナやAOP使う利点がなくなるの?
0843nobodyさん
2007/12/02(日) 15:18:44ID:???0844nobodyさん
2007/12/02(日) 17:07:56ID:???個人的にはHawkさんこそ復帰して欲しい・・・。
0845nobodyさん
2007/12/02(日) 18:01:06ID:???って気づいちゃった人だったけ?
0846nobodyさん
2007/12/02(日) 19:03:29ID:???横レスすまんけど
DIつう仕組みがすでにあるのに俺俺ファクトリーみたいなのを使う理由って何だ?
煽りじゃなくて単純な疑問。答えてくれるとうれしい
0847nobodyさん
2007/12/02(日) 20:19:53ID:???必要ないから。大げさだから。学習コストがかかるから。
俺俺ファクトリーで済むのにわざわざDIを使う理由は何だ?
Javaは融通がきかないからDIコンテナを使うのはわかる。
でも何でも実行時に行うスクリプト言語でわざわざ手間掛けてDIコンテナを使う理由はあるのか?
設定ファイル(config.php):
<?php $klass = 'Foo'; ?>
main.php:
<?php require_once('config.php'); $obj = new $klass(); ?>
これですむような言語にDIなんて必要ないだろ。
0848844
2007/12/02(日) 21:17:48ID:???お前Hawkさんとこに糞なコメント残したtestと同じタイプか?
何かしらプライベートであったからあーいう結末になったんだろ?
俺はあの人のサイトには随分世話になったんだ。
そういう言い方すんな、日本のPHP界にとっても有益な人だっんだ。
0849nobodyさん
2007/12/02(日) 21:27:44ID:???これでいいかな?
0850nobodyさん
2007/12/02(日) 22:03:43ID:???0851nobodyさん
2007/12/02(日) 22:21:46ID:???糞なコメントって何だ?
事情は知らんが印象に残ってただけで中傷する意図はない
プライベートどうこうじゃなくて個人の資質の問題だろう
気づいたこと自体は気づかないままよりいいんじゃね
0853nobodyさん
2007/12/03(月) 01:09:56ID:???0854nobodyさん
2007/12/03(月) 01:37:18ID:???俺俺ファクトリーもそうだけど、ソースの修正量が増えたときに
インスタンス管理なんかを誰が管理しなくちゃ行けない場面が沢山あるんだよ。
少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
確かに俺俺ファクトリーでも十分使えるけど
>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。
だから、みんなでコンテナに登録してテストとかの際に切り替えは
コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。
また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
そのソースの修正を待たずに、処理を追加できる利点があるんだ。
ソースの完了を待って、自分のコードを書くのじゃ遅いから、
あらかじめインタフェースとかを切っておいて決まり事をつける事で
誰かに待たされる事なくプログラムを進める事ができるんだ。
って、長文すまん
0855nobodyさん
2007/12/03(月) 01:43:48ID:???コンパクトで少人数なら俺俺、でかくて大人数ならDI、とかそういう感じ?
0856nobodyさん
2007/12/03(月) 03:11:05ID:???>少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で
>なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。
>確かに俺俺ファクトリーでも十分使えるけど
>>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。
おまえが何を問題にしているのかを明確にしてほしいんだけど、「(インスタンス管理のための)コードが、実際に動く部分に混入するとそれこそ苦労倍増」になることが問題ということでOK?
この前提が正しいとしたら、解答は「混入させない」。混入してたらそれはバグだから修正する。それだけ。
でもこれってJavaでも一緒だよね。Javaだと混入させない魔法でもあるの?
>だから、みんなでコンテナに登録してテストとかの際に切り替えは
>コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。
だからそんなことはDIじゃなくても十分できるの。特にスクリプト言語なら。
>また、AOPについては前にも書いたけど、誰かがソースを修正しているときに
>そのソースの修正を待たずに、処理を追加できる利点があるんだ。
違うだろ。AOPの利点は次の2つ。
* 既存のクラスに手を加えることなく処理を追加できること
* クラス階層を横断して機能を追加できること
>ソースの完了を待って、自分のコードを書くのじゃ遅いから、
>あらかじめインタフェースとかを切っておいて決まり事をつける事で
>誰かに待たされる事なくプログラムを進める事ができるんだ。
それはAOP関係なくて、mockとかdriverとかstubとかいうものでやること。AOPである必要はない。
0857nobodyさん
2007/12/03(月) 03:56:12ID:???0858nobodyさん
2007/12/03(月) 10:25:24ID:aJcrBH5W0859nobodyさん
2007/12/03(月) 11:07:06ID:???0860nobodyさん
2007/12/03(月) 11:18:21ID:???って完全にスレ違いだな。スマソ
0861nobodyさん
2007/12/03(月) 11:31:44ID:???【総合】PHPフレームワークを語るスレ8
http://pc11.2ch.net/test/read.cgi/php/1192604501/l50
0862nobodyさん
2007/12/03(月) 18:20:40ID:???MD5脂肪でPHP脂肪wwww
0864nobodyさん
2007/12/03(月) 21:09:02ID:???0866nobodyさん
2007/12/04(火) 00:23:04ID:???きっとDIとAOPがはやってるからという理由で勉強したJavaプログラマー、社会人3年目くらいか。
0867nobodyさん
2007/12/04(火) 00:43:22ID:???使える場面では使ってもいいとおもうよ>DI
少なくとも毛嫌いするようなもんでもないと思う
0868nobodyさん
2007/12/04(火) 00:47:26ID:???0869nobodyさん
2007/12/04(火) 00:48:51ID:???PHPを比べてる時点でナンセンスだと思うけどね
0870nobodyさん
2007/12/04(火) 01:08:03ID:???人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
>少なくとも毛嫌いするようなもんでもないと思う
嫌ってるんじゃなくて、DIコンテナを使ってうれしい場面がPHPではないってことだろ。好き嫌いの話じゃない。
そんなにいうなら、どう嬉しいのかをちゃんと語ればいいじゃん。ちゃんと説得力を持って。
説得力のある理由がでてきてないから必要ないといわれるわけで。
0872nobodyさん
2007/12/04(火) 01:31:29ID:???俺の低レベルな理解力では次のように理解
DI:クラスを置き換えできる。
AOP:メソッドを追加したり置き換えできる。
Mock:DIと同じ?(DIをテスト用途で使うことに特化した呼び名?)
あとmixinってのもあるよね。
mixin=AOP?
0873nobodyさん
2007/12/04(火) 10:29:36ID:???AOPは既存処理の前後に共通化された処理を挿入する。(前後とは限らない?)
mix-inは、共通で使う処理を関数化しておいて、それを任意のクラスのメソッドとして使えるようにする。
とか俺も半端な知識で言っている。
てかスレ違い。この辺の議論やると終わらないし。
0874nobodyさん
2007/12/04(火) 12:15:47ID:???scarletとか手軽そうだね
0875nobodyさん
2007/12/04(火) 12:38:33ID:???>人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。
少なくとも同じじゃないだろ
俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
>>870自身がどんな場合でもファクトリパターンで対応して
DIなんていらねーって言うんならもう何も言うことないけど
0876nobodyさん
2007/12/04(火) 16:47:36ID:???>俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ
コードって、どれを指してる?
例えば>>847の例だと設定ファイルとメインファイルの両方ともPHPのコードなんだけど、どっちのコードの見通しが悪くなると思ってる?
>DIなんていらねーって言うんならもう何も言うことないけど
DIの概念自体を否定してるんじゃなくて、何でも動的なスクリプト言語ならDIコンテナをわざわざ導入する必要がないといってるだけ。
DIでやろうとしていることは、スクリプト言語なら言語仕様の範囲で簡単に実現できる。
PHPでもDIコンテナが役に立つ例をだれも出せてないじゃん。それを示せばみんな納得できるのに、出しもしないでDIマンセーされてもな。
0877nobodyさん
2007/12/04(火) 18:03:00ID:???PHPでウェブプログラミングなんて、そもそも小規模なのばっかだし。
0878nobodyさん
2007/12/04(火) 18:30:24ID:???・DIの概念はPHPにおいても有効である。
・ただし、PHPでは>>847のように比較的簡単に実現できる。
・大掛かりな仕組みは必要ないじゃん。
JavaではDI必須。っていうのが当たり前になりつつあるようだけど
スクリプト言語では>>847のように比較的簡単にできてしまうことが、
静的型付き言語であるJavaでは一筋縄では実現できないから、Springとか
Seasarとかそういう大掛かりな仕組みが必要ってだけじゃない?
あと、Java的にはDI使うとクラス関係が疎結合になり
コンパイルが早くなるらしいね。
PHPの場合、大掛かりなDIを導入するメリットがJavaほどには無いように思う。
>>877そういうなよ。
なぜ、ぶった切ろうとする?
新しい話題提供できるならして欲しい。
DIについて話題になったのは、このスレでは初めてじゃない?
smarty必要か?PHPにフレームワークは必要か?とか
毎度毎度の定期ループしてる話題よりよほど良いと思うがな。
0879nobodyさん
2007/12/04(火) 19:29:14ID:???気にすることないよ。
0880nobodyさん
2007/12/04(火) 19:47:46ID:???AOPについではどうだろうか。
JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。
というか、AOPなしだとDIのメリットは半減する。
・PHPでもAOPは有効か?(どんなときに?)
・PHPではAOPも簡単に実現できるか?(YESなら大掛かりな仕組みはいらない)
0881877
2007/12/04(火) 20:39:47ID:???てかjavaでもいいや。xmlに書くとかもうウンザリ。
コード読んだ方がどこで何やってるかわかりやすいわ。
他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。
だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。
0882nobodyさん
2007/12/05(水) 01:58:35ID:???以前開発していたちょっと中規模なプロジェクトがあったんだけど、
そのプロジェクトは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のメリットはこんな感じだった。
スクリプト言語でも十分使えると思う。管理という面においては。
0883nobodyさん
2007/12/05(水) 02:04:50ID:???Apache 2.0系、2.2系にクロスサイトスクリプティングの脆弱性
Apache脂肪でPHPまたもや脂肪www
0886nobodyさん
2007/12/05(水) 09:18:00ID:???>ときどきデバッグ用に
>$hoge = 'OtherClass'
>とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。
これはデバッグ用のコードが本番用コードに紛れ込んでいたという話だよね?DI関係なくね?
DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。
>あと、依存関係が全然整理されてなくて
依存関係って、例えばどんなの?イメージがわからん。具体例で詳しく。
>何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。
これ、DIコンテナで解消できるの?
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これは言語の仕様によるものであって、DIを導入したからといって変わることはないはずだけど。
>(ドキュメントがあまり書かれてなかったんだよね...)
逆にいえば、ドキュメントを書けば済む話?
0887nobodyさん
2007/12/05(水) 10:42:51ID:???>DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。
いや、そういう意味ではなく、デバッグコードが混在してしまったけど、それを探すのに非常に手間がかかるってことをいいたい。
スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
だからコンテナをファクトリみたいに使って記述を統一した。
ここに、設定ファイル云々は関係ない
>これ、DIコンテナで解消できるの?
Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。
これこそがDI導入によるメリットだと思うが?必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
だからへたにnewするんじゃなくて、newするものをコンテナに置く。
>逆にいえば、ドキュメントを書けば済む話?
ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
でも依存関係とかってドキュメントしにくい部品でもある
0888nobodyさん
2007/12/05(水) 11:58:35ID:???>スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない
>だからコンテナをファクトリみたいに使って記述を統一した。
>ここに、設定ファイル云々は関係ない
いやだからさ、JavaでApplication.javaとconfig.xmlがあって、同じことをPHPでApplication.phpとconfig.phpにするとしよう。
デバッグコードはApplication.{java,php}に書いたの?それで分からなくなったというなら、それはDIも何も関係ないじゃん?どう関係あるの?
デバッグコードをconfig.{java,php}に書いて分からなくなったとしたなら、いくらなんでもセンスなさすぎだろ。config.phpで分からなくなるやつがconfig.xmlにしたところで解決できるわけない。
>これこそがDI導入によるメリットだと思うが?必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。
>だからへたにnewするんじゃなくて、newするものをコンテナに置く。
これも分からん。まず依存関係が何かを具体例で説明してくれ。
それと、newするものをXMLファイルに書くのと、同じことをPHPファイルに書くことと、どう違うのかちゃんと説明してくれ。
>ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。
>でも依存関係とかってドキュメントしにくい部品でもある
だから何をもって依存関係といってるの
0890nobodyさん
2007/12/05(水) 12:21:46ID:???Application.javaとconfig.xmlはこんなのね。
--- Application.java ---
S2Container container = S2ContainerFactory.create("config.xml");
InterfaceX obj = (InterfaceX)container.getComponent(ClassX.class);
--- config.xml ---
<component class="ClassX">
<initMethod name="initialize">
<arg>"foo"</arg>
<arg>123</arg>
</initMethod>
</component>
Application.phpとconfig.phpならこんな感じ。
--- Application.php ---
require_once("congif.php");
$obj = create_ClassX();
--- config.php ---
function create_ClassX() {
$obj = new ClassX();
$obj->initialize("foo", 123);
return $obj;
}
これらになんか違いがあるのか?
config.phpなら混乱するのがconfig.xmlでは混乱しないという理由を示してくれ。
0891887じゃないけど
2007/12/05(水) 12:49:30ID:???してもらいたいと感じてしまう。
もっと規模が大きくなってから大々的な移行しなきゃならなくなって
設定ファイルを再利用する場合とか、XSLT等で簡単&きれいに移行
できるし。
で、もしDIの設定にXML使うとすると、DIコンテナがその辺りのこと
を面倒見てくれるんだったら、それだけでも利用価値ありそう。
0892nobodyさん
2007/12/05(水) 12:50:34ID:???0893nobodyさん
2007/12/05(水) 13:36:32ID:???0894nobodyさん
2007/12/05(水) 13:52:03ID:???利点ってそれだけ?
Java使ってる他のやつに聞きたいんだけど、設定ファイルをXSLT使って移行するなんてこと本当にするの?そんなプロジェクト今まで見たことも聞いたこともない。
891はほんとにそれをしたことあるの?あるかもしれないという妄想を語っても仕方なくね?
それにおまえのconfig.xmlは手作業での移行ができないほど巨大なのか?おれはせいぜい50行いかない程度なんだけど。
数十行の移行をXSLTで自動化するためだけに、わざわざDIコンテナを勉強して導入するコストは払えん。しかもそんな場面が将来あるかどうかも分からないのに。
0895nobodyさん
2007/12/05(水) 14:03:29ID:???ないないw
ありもしないことを想定して無駄に作業増やすのがJava厨。
strutsのときも、フォワードのパスとかバリデータとか全部XML。
こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
っていったらビルドのコストがとわけのわからないことを言う。
Java厨って変更の可能性のあるところは全部XMLに追い出した方が
保守性が高いという妄想に取り憑かれすぎ。
XMLに追い出すとソースと2重管理になってウザイって。
DBの設定とかローカライズのメッセージとか、そういうのだけでいいよ。
クラスの名前とかそんなもん追い出すとろくなことにならない。
0896nobodyさん
2007/12/05(水) 14:32:00ID:???設定値を書きたくないという気持ちは理解できる。
0897895
2007/12/05(水) 14:35:03ID:???クラス名は設定値じゃないからなー
言語に依存してる物はソースに書く方が俺は良いと思う。
DIとか使わなくてもまともに動いて保守性の高いプログラムは書ける。
だったら使わない方法で俺は行く。
0898nobodyさん
2007/12/05(水) 14:39:05ID:???DI否定しないと気がすまんのな
0899nobodyさん
2007/12/05(水) 15:13:55ID:???0900nobodyさん
2007/12/05(水) 15:33:26ID:???>strutsのときも、フォワードのパスとかバリデータとか全部XML。
>こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・
禿同
XMLに外だししなくてもいいものまで外だししないといけないのがアホらしい。
入力→確認→登録だけの簡単なページ遷移もXMLに書くのが面倒くさくて仕方なかった。
遷移先が変更になることなんかないんだって、簡単なアプリなら。
面倒を強制するな。
0901nobodyさん
2007/12/05(水) 15:36:14ID:???俺の場合はPHPとは全く関係ないが、すでに出来上がってるシステムの
スケーラビリティ向上+UIの一新を目的に大部分を書き直したことある
けど、そのときに設定ファイルの変更点はかなり少なかったからXSLT
使ったよ。
別に設定ファイルがデカイからではなく、そのシステムをデプロイして
使っている人が多かったから一挙に対応するために移行用のXSLT用意し
たらずいぶんあっさり終わった。
0903nobodyさん
2007/12/05(水) 16:40:47ID:???どれ使おうかと探したが、まあ一応本家だしZend試してみようかとサイトいったんだが
どうにもつながんねえ。
Zendframeworkって今落とせるのか?
ttp://framework.zend.com/
ここ自体応答無しなんだけど。
0905nobodyさん
2007/12/05(水) 17:09:29ID:???こっからZend Studioの評価版落としてインスコ
インスコ先のbin\ZendFramework\libraryにFrameworkが入ってるお
0906nobodyさん
2007/12/05(水) 17:30:30ID:???>>905
たまたまっぽいんで復旧するまでまつことにするわ。
余計なのインスコしてレジストリ汚したくないし。
でも情報thx
0907nobodyさん
2007/12/05(水) 18:44:23ID:???依存関係の注入やインスタンス管理をまとめてコンテナがやってくれる事じゃないの?
つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
この場で作ったCのオブジェクトににセットして…
とかみたいなコードをいちいち書かなくて済むようになる事こそがメリットだと思う。
0908907
2007/12/05(水) 18:49:05ID:???0909nobodyさん
2007/12/05(水) 18:50:44ID:???これもDIコンテナなしで十分実現できるんだろうけど、せっかくだしもうちょっと話を聞かせてもらおうか。
>つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、
>この場で作ったCのオブジェクトににセットして…
ここらへんを詳しく。DIコンテナのメリットが分かるような具体例つきで。
0910nobodyさん
2007/12/05(水) 20:13:07ID:???DIコンテナなしでも実現できるから
DIコンテナいらないってのはなんかちょっと違うと思う
Javaは機能毎にコンポーネントを細かく切りまくって
ひとつひとつは小さい機能でたくさんのクラスを用意する傾向がある
(PHPをはじめとするスクリプト言語と比較してという意味で)
でそのたくさんのクラスをできるだけ疎結合にするために
ConstructorInjectionなりSetterInjectionなりで
外部からインスタンスを注入するようする、
それがDependency Injection(であってるよな、、)
そうした際に、ある機能(モジュール)を使いたいと思ったときにも
上に書いたようにクラスが細かく分かれているから
様々なインスタンスを注入しなければならなくなる、
AというモジュールはBの注入が必要でBはCとDが、DはEが・・・
とインスタンス間の依存性が複雑になっていった時に、
いちいちその注入のためのコードを毎回書き直して
コンパイルし直すような手間を減らすのが
DIコンテナの役割だと思うんだけど
>>907もおそらくこういうニュアンスだったと思うんだが
俺も別にスクリプト言語でDIコンテナとかいらないと思う
スクリプト言語だと比較的(Javaと比べて)多機能の大きなクラスを作るし
コンテナで管理しないと困るなあと思うほど
インスタンス間の依存関係が複雑になるケースがそんなにないから
そういう意味でPHPにDIコンテナは要らんってのは分かるけど
DIコンテナという仕組み自体が要らんとかだめだとか
それはまたちょっと違う問題じゃないのという気はする
0911nobodyさん
2007/12/05(水) 20:51:19ID:???でもなんにせよJavaのやり方って普及しないよね。
Javaの崇高なる理論を元にした設計方針
→バカは理解できないから徹底は難しい
優秀なエンジニアの集団
→そのプロジェクトで一番効率的なやり方を自分たちで編み出してやる
0912nobodyさん
2007/12/05(水) 22:00:20ID:???0913nobodyさん
2007/12/05(水) 22:10:55ID:???0914nobodyさん
2007/12/06(木) 00:19:55ID:???だから具体例で説明しろって。
依存関係というのが複雑な例を出して、そのXMLを書いてみせろ。
そしてそれがPHPコードで書くと複雑になるのが、DIコンテナだとすっきり書けるというのを実際に書いて示せ。
具体例を示さずにDIマンセーするのウゼエ
0916nobodyさん
2007/12/06(木) 00:38:46ID:???0917nobodyさん
2007/12/06(木) 00:41:48ID:???0918nobodyさん
2007/12/06(木) 01:18:29ID:???0919nobodyさん
2007/12/06(木) 02:05:44ID:???0920nobodyさん
2007/12/06(木) 10:46:27ID:???http://news.livedoor.com/article/detail/3417675/
0921nobodyさん
2007/12/06(木) 11:19:50ID:???っていうか具体例だしても、挙げ足なら誰も書けないと思うんだけど。
0922nobodyさん
2007/12/06(木) 11:23:59ID:???一連の書き込み見てりゃわかるけど
0926nobodyさん
2007/12/06(木) 17:06:31ID:???DAT落ちしそうですが、一昨日から試行錯誤しても駄目だったので冒険します。
PRADOのSqlMapについてなんですが
やりたいこと:
〜略〜->QueryForList( 'FooBar', array( '%aaaa%', '%bbb%') );
から、
SELECT * FROM table WHERE ( str Like '%aaaa%' OR str Like '%bbb%' )
に展開して結果を取得したい。(配列数は可変)
やった事:
SqlMap.xml に、
<statement id="FooBar" parameterClass="array">
SELECT * FROM site WHERE
<iterate open="(" close=")" conjunction=" OR ">
str Like #[]#
</iterate>
</statement>
を追記したのですが
Unable to find property '[]' in object 'false' for parameter map 'FooBar-InLineParameterMap'
と出てうまくいきません。
PRADOのSqlMap Manualには <iterate> について書かれていないし、参考にしたのが
ttp://trac.pradosoft.com/prado/browser/trunk/tests/unit/SQLMap/maps/sqlite/DynamicAccount.xml
だったりするのでまだ未実装なのか記述ミスなのかもわかりません。。。
どうやったらうまくいくのかヒントでも何でもいいので、お示しをお願いします。。。
0927nobodyさん
2007/12/06(木) 17:13:51ID:???0928nobodyさん
2007/12/08(土) 05:30:02ID:???OSX脂肪でPHP脂肪www
0929nobodyさん
2007/12/08(土) 17:30:22ID:???同じスクリプト言語でもPerlなら付きます
PHPしかしないのは技術者として自殺行為です
初心者こそ最初は他の言語をしましょうね
レス数が900を超えています。1000を超えると表示できなくなるよ。