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

1 名前：nobodyさん [2007/10/17(水) 16:01:41 ID:72/gWtt1] 前スレ pc11.2ch.net/test/read.cgi/php/1181350116/ 854 名前：nobodyさん mailto:sage [2007/12/03(月) 01:37:18 ID:???] >>847 俺俺ファクトリーもそうだけど、ソースの修正量が増えたときに インスタンス管理なんかを誰が管理しなくちゃ行けない場面が沢山あるんだよ。 少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。 確かに俺俺ファクトリーでも十分使えるけど >>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。 だから、みんなでコンテナに登録してテストとかの際に切り替えは コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。 また、AOPについては前にも書いたけど、誰かがソースを修正しているときに そのソースの修正を待たずに、処理を追加できる利点があるんだ。 ソースの完了を待って、自分のコードを書くのじゃ遅いから、 あらかじめインタフェースとかを切っておいて決まり事をつける事で 誰かに待たされる事なくプログラムを進める事ができるんだ。 って、長文すまん 855 名前：nobodyさん mailto:sage [2007/12/03(月) 01:43:48 ID:???] 俺俺ファクトリーかDIかっていうのは結局のところ程度問題なわけか？ コンパクトで少人数なら俺俺、でかくて大人数ならDI、とかそういう感じ？ 856 名前：nobodyさん mailto:sage [2007/12/03(月) 03:11:05 ID:???] >>854 >少人数でソースの管理を行っているなら、コミットログとかコミュニケーションの範疇で >なんとかなるけど、規模が大きくなってくるとそれが大変になってくるんだ。 >確かに俺俺ファクトリーでも十分使えるけど >>>847 の書いたようなコードが、実際に動く部分に混入するとそれこそ苦労倍増なんだよ。 おまえが何を問題にしているのかを明確にしてほしいんだけど、「（インスタンス管理のための）コードが、実際に動く部分に混入するとそれこそ苦労倍増」になることが問題ということでOK？ この前提が正しいとしたら、解答は「混入させない」。混入してたらそれはバグだから修正する。それだけ。 でもこれってJavaでも一緒だよね。Javaだと混入させない魔法でもあるの？ >だから、みんなでコンテナに登録してテストとかの際に切り替えは >コンテナからやっちゃいましょうね。っていう仕組みがDIで簡単にできる。 だからそんなことはDIじゃなくても十分できるの。特にスクリプト言語なら。 >また、AOPについては前にも書いたけど、誰かがソースを修正しているときに >そのソースの修正を待たずに、処理を追加できる利点があるんだ。 違うだろ。AOPの利点は次の2つ。 * 既存のクラスに手を加えることなく処理を追加できること * クラス階層を横断して機能を追加できること >ソースの完了を待って、自分のコードを書くのじゃ遅いから、 >あらかじめインタフェースとかを切っておいて決まり事をつける事で >誰かに待たされる事なくプログラムを進める事ができるんだ。 それはAOP関係なくて、mockとかdriverとかstubとかいうものでやること。AOPである必要はない。 857 名前：nobodyさん mailto:sage [2007/12/03(月) 03:56:12 ID:???] 白熱だなあ 858 名前：nobodyさん [2007/12/03(月) 10:25:24 ID:aJcrBH5W] AOPとかDIとかよくわかってない俺 859 名前：nobodyさん mailto:sage [2007/12/03(月) 11:07:06 ID:???] AOPとかDIとか全くわかってない俺も来ましたよ 860 名前：nobodyさん mailto:sage [2007/12/03(月) 11:18:21 ID:???] 誰か忘れたけど、Perl on Railsを作ってるみたいだね。 って完全にスレ違いだな。ｽﾏｿ 861 名前：nobodyさん mailto:sage [2007/12/03(月) 11:31:44 ID:???] >>860 どの言語でもパクれるんですね。　んならPHPでいいや。 【総合】PHPフレームワークを語るスレ8 pc11.2ch.net/test/read.cgi/php/1192604501/l50 862 名前：nobodyさん mailto:sage [2007/12/03(月) 18:20:40 ID:???] slashdot.jp/security/article.pl?sid=07/12/02/1931233 MD5脂肪でPHP脂肪ｗｗｗｗ 863 名前：nobodyさん mailto:sage [2007/12/03(月) 18:35:44 ID:???] >>862は釣りですか 864 名前：nobodyさん mailto:sage [2007/12/03(月) 21:09:02 ID:???] MD5脂肪→PHPはセッションでMD5値を使っている→三段論法でPHP脂肪ｗｗｗ 865 名前：nobodyさん mailto:sage [2007/12/03(月) 22:25:35 ID:???] >>864も釣りですか 866 名前：nobodyさん mailto:sage [2007/12/04(火) 00:23:04 ID:???] Javaで有効だったからPHPでも有効だと思ってるやついるね。 きっとDIとAOPがはやってるからという理由で勉強したJavaプログラマー、社会人3年目くらいか。 867 名前：nobodyさん mailto:sage [2007/12/04(火) 00:43:22 ID:???] 個人的には人が書いた俺俺ファクトリーをいじるの(っていうかコード見るの)はやだなあ 使える場面では使ってもいいとおもうよ>DI 少なくとも毛嫌いするようなもんでもないと思う 868 名前：nobodyさん mailto:sage [2007/12/04(火) 00:47:26 ID:???] そんなに駄目かな？ＤＩ。 869 名前：nobodyさん mailto:sage [2007/12/04(火) 00:48:51 ID:???] 静的型付け言語であるJavaと PHPを比べてる時点でナンセンスだと思うけどね 870 名前：nobodyさん mailto:sage [2007/12/04(火) 01:08:03 ID:???] >>867 人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。 >少なくとも毛嫌いするようなもんでもないと思う 嫌ってるんじゃなくて、DIコンテナを使ってうれしい場面がPHPではないってことだろ。好き嫌いの話じゃない。 そんなにいうなら、どう嬉しいのかをちゃんと語ればいいじゃん。ちゃんと説得力を持って。 説得力のある理由がでてきてないから必要ないといわれるわけで。 871 名前：nobodyさん mailto:sage [2007/12/04(火) 01:23:40 ID:???] >>869 スクリプト言語にDIを勧めるほうがナンセンス 872 名前：nobodyさん mailto:sage [2007/12/04(火) 01:31:29 ID:???] DIとMockとAOPの違いを簡潔に教えて頂戴＞えろい方 俺の低レベルな理解力では次のように理解 DI：クラスを置き換えできる。 AOP：メソッドを追加したり置き換えできる。 Mock：DIと同じ？（DIをテスト用途で使うことに特化した呼び名？） あとmixinってのもあるよね。 mixin＝AOP？ 873 名前：nobodyさん mailto:sage [2007/12/04(火) 10:29:36 ID:???] >>872 AOPは既存処理の前後に共通化された処理を挿入する。（前後とは限らない？） mix-inは、共通で使う処理を関数化しておいて、それを任意のクラスのメソッドとして使えるようにする。 とか俺も半端な知識で言っている。 てかスレ違い。この辺の議論やると終わらないし。 874 名前：nobodyさん mailto:sage [2007/12/04(火) 12:15:47 ID:???] phpで使えるdiコンテナてあるのな scarletとか手軽そうだね 875 名前：nobodyさん mailto:sage [2007/12/04(火) 12:38:33 ID:???] >>870 >人が書いた俺オレfactoryと、人が書いたDIコンテナと、どう違うというのだろう。 少なくとも同じじゃないだろ 俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ >>870自身がどんな場合でもファクトリパターンで対応して DIなんていらねーって言うんならもう何も言うことないけど 876 名前：nobodyさん mailto:sage [2007/12/04(火) 16:47:36 ID:???] >>875 >俺俺ファクトリーだと、大規模化したときコードの見通し悪くなるよ コードって、どれを指してる？ 例えば>>847の例だと設定ファイルとメインファイルの両方ともPHPのコードなんだけど、どっちのコードの見通しが悪くなると思ってる？ >DIなんていらねーって言うんならもう何も言うことないけど DIの概念自体を否定してるんじゃなくて、何でも動的なスクリプト言語ならDIコンテナをわざわざ導入する必要がないといってるだけ。 DIでやろうとしていることは、スクリプト言語なら言語仕様の範囲で簡単に実現できる。 PHPでもDIコンテナが役に立つ例をだれも出せてないじゃん。それを示せばみんな納得できるのに、出しもしないでDIマンセーされてもな。 877 名前：nobodyさん mailto:sage [2007/12/04(火) 18:03:00 ID:???] ほっとけよ。DI議論はもういい。 PHPでウェブプログラミングなんて、そもそも小規模なのばっかだし。 878 名前：nobodyさん mailto:sage [2007/12/04(火) 18:30:24 ID:???] まとめようか。 ・DIの概念はPHPにおいても有効である。 ・ただし、PHPでは>>847のように比較的簡単に実現できる。 ・大掛かりな仕組みは必要ないじゃん。 JavaではDI必須。っていうのが当たり前になりつつあるようだけど スクリプト言語では>>847のように比較的簡単にできてしまうことが、 静的型付き言語であるJavaでは一筋縄では実現できないから、Springとか Seasarとかそういう大掛かりな仕組みが必要ってだけじゃない？ あと、Java的にはDI使うとクラス関係が疎結合になり コンパイルが早くなるらしいね。 PHPの場合、大掛かりなDIを導入するメリットがJavaほどには無いように思う。 >>877そういうなよ。 なぜ、ぶった切ろうとする？ 新しい話題提供できるならして欲しい。 DIについて話題になったのは、このスレでは初めてじゃない？ smarty必要か？PHPにフレームワークは必要か？とか 毎度毎度の定期ループしてる話題よりよほど良いと思うがな。 879 名前：nobodyさん mailto:sage [2007/12/04(火) 19:29:14 ID:???] 自分が分からない話題が続くとイライラしちゃうんじゃないの？たぶん。 気にすることないよ。 880 名前：nobodyさん mailto:sage [2007/12/04(火) 19:47:46 ID:???] >>878 AOPについではどうだろうか。 JavaでDIのメリットの一つとして、AOPが簡単にできることが挙げられる。 というか、AOPなしだとDIのメリットは半減する。 ・PHPでもAOPは有効か？（どんなときに？） ・PHPではAOPも簡単に実現できるか？（YESなら大掛かりな仕組みはいらない） 881 名前：877 mailto:sage [2007/12/04(火) 20:39:47 ID:???] いや俺はDIいらないでおk。スクリプト言語にはナンセンスで。 てかjavaでもいいや。xmlに書くとかもうウンザリ。 コード読んだ方がどこで何やってるかわかりやすいわ。 他人の俺俺ファクトリーでもスキルある奴が作ってればそれでいい。 だいたいソース読んで困るのは、ファクトリとかそんな知識すらないバカのだし。 882 名前：nobodyさん mailto:sage [2007/12/05(水) 01:58:35 ID:???] 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のメリットはこんな感じだった。 スクリプト言語でも十分使えると思う。管理という面においては。 883 名前：nobodyさん mailto:sage [2007/12/05(水) 02:04:50 ID:???] japan.zdnet.com/security/story/0,3800079245,20362451,00.htm Apache 2.0系、2.2系にクロスサイトスクリプティングの脆弱性 Apache脂肪でPHPまたもや脂肪ｗｗｗ 884 名前：nobodyさん mailto:sage [2007/12/05(水) 02:15:00 ID:???] >>883 先生！これはPHPだけの問題なのですか？ 885 名前：nobodyさん mailto:sage [2007/12/05(水) 08:48:32 ID:???] >>884 そういうことにしといてやれ もしくはスルーで 886 名前：nobodyさん mailto:sage [2007/12/05(水) 09:18:00 ID:???] >>882 >ときどきデバッグ用に >$hoge = 'OtherClass' >とかって書いちゃってるコードが混入して、結合テストがすごく大変だったトラウマがある。 これはデバッグ用のコードが本番用コードに紛れ込んでいたという話だよね？DI関係なくね？ DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。 >あと、依存関係が全然整理されてなくて 依存関係って、例えばどんなの？イメージがわからん。具体例で詳しく。 >何をnewできるのか、何が newされる対象なのかがわからなくて、保守のときに大変だったトラ ウマがある。 これ、DIコンテナで解消できるの？ Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。 これは言語の仕様によるものであって、DIを導入したからといって変わることはないはずだけど。 >（ドキュメントがあまり書かれてなかったんだよね...) 逆にいえば、ドキュメントを書けば済む話？ 887 名前：nobodyさん mailto:sage [2007/12/05(水) 10:42:51 ID:???] >>886 >DIコンテナ使ってても、各自がデバッグ用にconfig.xmlをいじって、それが本番環境に反映されたら同じことだよね。 いや、そういう意味ではなく、デバッグコードが混在してしまったけど、それを探すのに非常に手間がかかるってことをいいたい。 スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない だからコンテナをファクトリみたいに使って記述を統一した。 ここに、設定ファイル云々は関係ない >これ、DIコンテナで解消できるの？ Javaはclassやinterfaceを使って型を縛れるから、どんなオブジェクトを指定できるかはわかるけど、PHPは変数に型がないから、どんなオブジェクトがくるかは指定できない。 これこそがDI導入によるメリットだと思うが？必要とされるべきオブジェクトはコンテナによって注入される事で、依存関係を解決できるでしょ。 だからへたにnewするんじゃなくて、newするものをコンテナに置く。 >逆にいえば、ドキュメントを書けば済む話？ ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。 でも依存関係とかってドキュメントしにくい部品でもある 888 名前：nobodyさん mailto:sage [2007/12/05(水) 11:58:35 ID:???] >>886 >スクリプト言語だから、どこかで変数を変更してもデバッグそるまで、どう動くのか分からない >だからコンテナをファクトリみたいに使って記述を統一した。 >ここに、設定ファイル云々は関係ない いやだからさ、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ファイルに書くことと、どう違うのかちゃんと説明してくれ。 >ぶっちゃけいえばそうだね、ドキュメントに事細かに書かれてれば大丈夫だったと思う。 >でも依存関係とかってドキュメントしにくい部品でもある だから何をもって依存関係といってるの 889 名前：nobodyさん mailto:sage [2007/12/05(水) 12:17:17 ID:???] ごめん、>>886じゃなくて>>887でした。 890 名前：nobodyさん mailto:sage [2007/12/05(水) 12:21:46 ID:???] >>887 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では混乱しないという理由を示してくれ。 891 名前：887じゃないけど mailto:sage [2007/12/05(水) 12:49:30 ID:???] なんかそのコード見せられると、configファイルはさすがにXMLに してもらいたいと感じてしまう。 もっと規模が大きくなってから大々的な移行しなきゃならなくなって 設定ファイルを再利用する場合とか、XSLT等で簡単＆きれいに移行 できるし。 で、もしDIの設定にXML使うとすると、DIコンテナがその辺りのこと を面倒見てくれるんだったら、それだけでも利用価値ありそう。 892 名前：nobodyさん mailto:sage [2007/12/05(水) 12:50:34 ID:???] congif見てザンギエフ思い出した俺ガイル 893 名前：nobodyさん mailto:sage [2007/12/05(水) 13:36:32 ID:???] やっぱりXMLは醜悪だな。設定ファイルはS式にするべきだ。 894 名前：nobodyさん mailto:sage [2007/12/05(水) 13:52:03 ID:???] >>891 利点ってそれだけ？ Java使ってる他のやつに聞きたいんだけど、設定ファイルをXSLT使って移行するなんてこと本当にするの？そんなプロジェクト今まで見たことも聞いたこともない。 891はほんとにそれをしたことあるの？あるかもしれないという妄想を語っても仕方なくね？ それにおまえのconfig.xmlは手作業での移行ができないほど巨大なのか？おれはせいぜい50行いかない程度なんだけど。 数十行の移行をXSLTで自動化するためだけに、わざわざDIコンテナを勉強して導入するコストは払えん。しかもそんな場面が将来あるかどうかも分からないのに。 895 名前：nobodyさん mailto:sage [2007/12/05(水) 14:03:29 ID:???] >設定ファイルをXSLT使って移行するなんてこと本当にするの ないないw ありもしないことを想定して無駄に作業増やすのがJava厨。 strutsのときも、フォワードのパスとかバリデータとか全部XML。 こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・ っていったらビルドのコストがとわけのわからないことを言う。 Java厨って変更の可能性のあるところは全部XMLに追い出した方が 保守性が高いという妄想に取り憑かれすぎ。 XMLに追い出すとソースと2重管理になってウザイって。 DBの設定とかローカライズのメッセージとか、そういうのだけでいいよ。 クラスの名前とかそんなもん追い出すとろくなことにならない。 896 名前：nobodyさん mailto:sage [2007/12/05(水) 14:32:00 ID:???] まあCやらJavaやらコンパイル言語使うと、ソースファイルの中には 設定値を書きたくないという気持ちは理解できる。 897 名前：895 mailto:sage [2007/12/05(水) 14:35:03 ID:???] >>896 クラス名は設定値じゃないからなー 言語に依存してる物はソースに書く方が俺は良いと思う。 DIとか使わなくてもまともに動いて保守性の高いプログラムは書ける。 だったら使わない方法で俺は行く。 898 名前：nobodyさん mailto:sage [2007/12/05(水) 14:39:05 ID:???] ファクトリー厨の方々、必死すぎだろ DI否定しないと気がすまんのな 899 名前：nobodyさん mailto:sage [2007/12/05(水) 15:13:55 ID:???] DI否定する気は無いがPHPで使う気にはなれない 900 名前：nobodyさん mailto:sage [2007/12/05(水) 15:33:26 ID:???] >>895 >strutsのときも、フォワードのパスとかバリデータとか全部XML。 >こんなもんプログラムに埋め込んだ方がいいと思うんだけど・・・ 禿同 XMLに外だししなくてもいいものまで外だししないといけないのがアホらしい。 入力→確認→登録だけの簡単なページ遷移もXMLに書くのが面倒くさくて仕方なかった。 遷移先が変更になることなんかないんだって、簡単なアプリなら。 面倒を強制するな。 901 名前：nobodyさん mailto:sage [2007/12/05(水) 15:36:14 ID:???] >>894-895 俺の場合はPHPとは全く関係ないが、すでに出来上がってるシステムの スケーラビリティ向上＋UIの一新を目的に大部分を書き直したことある けど、そのときに設定ファイルの変更点はかなり少なかったからXSLT 使ったよ。 別に設定ファイルがデカイからではなく、そのシステムをデプロイして 使っている人が多かったから一挙に対応するために移行用のXSLT用意し たらずいぶんあっさり終わった。 902 名前：nobodyさん mailto:sage [2007/12/05(水) 15:42:51 ID:???] >>898 891=887乙 903 名前：nobodyさん mailto:sage [2007/12/05(水) 16:40:47 ID:???] PHP3年ぶりぐらいに使おうと思って色々調べて、最近はPHPもフレームワークかと思いつつ どれ使おうかと探したが、まあ一応本家だしZend試してみようかとサイトいったんだが どうにもつながんねえ。 Zendframeworkって今落とせるのか？ ttp://framework.zend.com/ ここ自体応答無しなんだけど。 904 名前：nobodyさん mailto:sage [2007/12/05(水) 17:01:28 ID:???] >>903 昨日はつながってたんだが、 つながらんね 905 名前：nobodyさん mailto:sage [2007/12/05(水) 17:09:29 ID:???] ttp://www.zend.com/en/ こっからZend Studioの評価版落としてインスコ インスコ先のbin\ZendFramework\libraryにFrameworkが入ってるお 906 名前：nobodyさん mailto:sage [2007/12/05(水) 17:30:30 ID:???] 3年ぶりのたまたまが偶然鯖落ちかなんかと重なったのか・・・ >>905 たまたまっぽいんで復旧するまでまつことにするわ。 余計なのインスコしてレジストリ汚したくないし。 でも情報thx 907 名前：nobodyさん mailto:sage [2007/12/05(水) 18:44:23 ID:???] DIContainerの利点は、クラス名を変えれる事ではなくて、 依存関係の注入やインスタンス管理をまとめてコンテナがやってくれる事じゃないの？ つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、 この場で作ったCのオブジェクトににセットして… とかみたいなコードをいちいち書かなくて済むようになる事こそがメリットだと思う。 908 名前：907 mailto:sage [2007/12/05(水) 18:49:05 ID:???] 2文目、書いたり消したりしてたら色々変になっちまった。スルーしてくれ。 909 名前：nobodyさん mailto:sage [2007/12/05(水) 18:50:44 ID:???] >>907 これもDIコンテナなしで十分実現できるんだろうけど、せっかくだしもうちょっと話を聞かせてもらおうか。 >つまり、あっちで作ったAのオブジェクトと、singletonのBのオブジェクトを、 >この場で作ったCのオブジェクトににセットして… ここらへんを詳しく。DIコンテナのメリットが分かるような具体例つきで。 910 名前：nobodyさん mailto:sage [2007/12/05(水) 20:13:07 ID:???] >>907じゃないけど、 DIコンテナなしでも実現できるから DIコンテナいらないってのはなんかちょっと違うと思う Javaは機能毎にコンポーネントを細かく切りまくって ひとつひとつは小さい機能でたくさんのクラスを用意する傾向がある （PHPをはじめとするスクリプト言語と比較してという意味で） でそのたくさんのクラスをできるだけ疎結合にするために ConstructorInjectionなりSetterInjectionなりで 外部からインスタンスを注入するようする、 それがDependency Injection（であってるよな、、） そうした際に、ある機能（モジュール）を使いたいと思ったときにも 上に書いたようにクラスが細かく分かれているから 様々なインスタンスを注入しなければならなくなる、 AというモジュールはBの注入が必要でBはCとDが、DはEが・・・ とインスタンス間の依存性が複雑になっていった時に、 いちいちその注入のためのコードを毎回書き直して コンパイルし直すような手間を減らすのが DIコンテナの役割だと思うんだけど >>907もおそらくこういうニュアンスだったと思うんだが 俺も別にスクリプト言語でDIコンテナとかいらないと思う スクリプト言語だと比較的（Javaと比べて）多機能の大きなクラスを作るし コンテナで管理しないと困るなあと思うほど インスタンス間の依存関係が複雑になるケースがそんなにないから そういう意味でPHPにDIコンテナは要らんってのは分かるけど DIコンテナという仕組み自体が要らんとかだめだとか それはまたちょっと違う問題じゃないのという気はする 911 名前：nobodyさん mailto:sage [2007/12/05(水) 20:51:19 ID:???] 結局好みの問題もあるしなー でもなんにせよJavaのやり方って普及しないよね。 Javaの崇高なる理論を元にした設計方針 →バカは理解できないから徹底は難しい 優秀なエンジニアの集団 →そのプロジェクトで一番効率的なやり方を自分たちで編み出してやる 912 名前：nobodyさん mailto:sage [2007/12/05(水) 22:00:20 ID:???] 結局好み 913 名前：nobodyさん mailto:sage [2007/12/05(水) 22:10:55 ID:???] JAVAの山に幾度か登ったけど、全てリタイヤ…　orz 914 名前：nobodyさん mailto:sage [2007/12/06(木) 00:19:55 ID:???] >>910 だから具体例で説明しろって。 依存関係というのが複雑な例を出して、そのXMLを書いてみせろ。 そしてそれがPHPコードで書くと複雑になるのが、DIコンテナだとすっきり書けるというのを実際に書いて示せ。 具体例を示さずにDIマンセーするのウゼエ 915 名前：nobodyさん mailto:sage [2007/12/06(木) 00:31:56 ID:???] >>910は別に DIマンセー と言ってるわけではないだろうが なんでも噛み付くおまえもウゼエ 916 名前：nobodyさん mailto:sage [2007/12/06(木) 00:38:46 ID:???] PHPER仲違いでPHP脂肪ｗｗｗ 917 名前：nobodyさん mailto:sage [2007/12/06(木) 00:41:48 ID:???] 何言っても具体例で説明しろとしか言えないんだろ 918 名前：nobodyさん mailto:sage [2007/12/06(木) 01:18:29 ID:???] DIコンテナ自体理解できないから具体例出して欲しいんだろうよ 919 名前：nobodyさん mailto:sage [2007/12/06(木) 02:05:44 ID:???] おまえらが具体例出せないことはよくわかった 920 名前：nobodyさん mailto:sage [2007/12/06(木) 10:46:27 ID:???] バイトがゴキブリ揚げてケンタッキー脂肪ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ news.livedoor.com/article/detail/3417675/ 921 名前：nobodyさん mailto:sage [2007/12/06(木) 11:19:50 ID:???] DIの具体例って前から説明されてね？ っていうか具体例だしても、挙げ足なら誰も書けないと思うんだけど。 922 名前：nobodyさん mailto:sage [2007/12/06(木) 11:23:59 ID:???] DIを理解できない頭の悪さを他人のせいにしてるだけだよ 一連の書き込み見てりゃわかるけど 923 名前：nobodyさん mailto:sage [2007/12/06(木) 13:32:45 ID:???] >>921 >DIの具体例って前から説明されてね？ どこに？ 924 名前：nobodyさん mailto:sage [2007/12/06(木) 13:35:42 ID:???] >>923に、わかりやすく言えば、班長さんみたいなもんだ。 925 名前：nobodyさん mailto:sage [2007/12/06(木) 13:42:24 ID:???] >>921の文章が難解だと思うのは俺だけでしょうか？ 926 名前：nobodyさん mailto:sage [2007/12/06(木) 17:06:31 ID:???] 残り少ないレス可能数に、DI 話で盛り上がってるのでスルーされてそのまま 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 だったりするのでまだ未実装なのか記述ミスなのかもわかりません。。。 どうやったらうまくいくのかヒントでも何でもいいので、お示しをお願いします。。。 927 名前：nobodyさん mailto:sage [2007/12/06(木) 17:13:51 ID:???] そんなの使わなければ、つまづく事も無いのにね。 928 名前：nobodyさん mailto:sage [2007/12/08(土) 05:30:02 ID:???] japan.zdnet.com/security/story/0,3800079245,20362715,00.htm OSX脂肪でPHP脂肪ｗｗｗ 929 名前：nobodyさん mailto:sage [2007/12/08(土) 17:30:22 ID:???] PHPやっててフォークやソケットやスレッドの知識が身に付きますか？ 同じスクリプト言語でもPerlなら付きます PHPしかしないのは技術者として自殺行為です 初心者こそ最初は他の言語をしましょうね 930 名前：nobodyさん mailto:sage [2007/12/09(日) 01:24:32 ID:???] PHPのことを知らないのなら 黙ってれば恥かかなくてすむのにねｗ 931 名前：nobodyさん mailto:sage [2007/12/09(日) 05:26:30 ID:???] PHP自体がフレームワーク 932 名前：nobodyさん mailto:sage [2007/12/09(日) 05:32:16 ID:???] まあフレームワークは制限だからな 933 名前：nobodyさん mailto:sage [2007/12/09(日) 05:33:35 ID:???] このスレを見ている人はこんなスレも見ています。(ver 0.20) フケ・痒みがとまらないPart9 [身体・健康] まだ止まらないのかよｗ 934 名前：nobodyさん mailto:sage [2007/12/09(日) 07:36:41 ID:???] もともとフレームワークのPHP使ってフレムーワーク作る人って恥ずかしくないのかなｗ 935 名前：nobodyさん mailto:sage [2007/12/09(日) 07:44:51 ID:???] そんな事言ったら、どの言語だってそうだろ。 ちなみにフレムーワークは作った事ないけど。 936 名前：nobodyさん [2007/12/09(日) 12:05:37 ID:v5bnJUO2] 俺もそろそろフレームワークデビューしてみたい（っ´∀｀）っ 937 名前：nobodyさん mailto:sage [2007/12/09(日) 12:20:44 ID:???] PHPはフレームワークとしては貧弱だからな １枚ぐらい皮を被せたくなるぞ 俺は薄い皮希望だがな 938 名前：nobodyさん mailto:sage [2007/12/09(日) 13:22:15 ID:???] より多くの案件をこなすのが目的なら CakePHP 導入までの敷居が低い　＝　設置できるレンタルサーバーが多くなる 難易度が低い　＝　多くの技術者がすぐにプロジェクト参加できる FWの程度が中規模 ＝　オリジナルなFWに変更しやすい したがってCakePHPがダントツに流行ることは間違いない 939 名前：nobodyさん mailto:sage [2007/12/09(日) 13:30:49 ID:???] 俺様分析おつかれさん 940 名前：nobodyさん mailto:sage [2007/12/09(日) 13:36:11 ID:???] RoRがどのレンタルサーバーでも標準装備されれば RoRが爆発的に流行すると思うが phpで出来ることをRoRを覚えてまでやる必要があるかどうか phpの豊富なWEB用ライブラリを超えることはまず不可能だと思う なぜならphpはWEBだけに特化した言語だから 941 名前：nobodyさん mailto:sage [2007/12/09(日) 13:40:00 ID:???] symfonyはFWにしては大掛かりすぎるのが難点 それゆえに自由度が利かない 案件に合わせてFWを選択するのが一番いいと思うが CakePHPならどの案件でも使える可能性が高い 942 名前：nobodyさん mailto:sage [2007/12/09(日) 13:42:29 ID:???] PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ 943 名前：nobodyさん mailto:sage [2007/12/09(日) 13:58:55 ID:???] 俺はcakeがどうだとかethnaがどうだとか言ってる奴が根絶するまで PHP4ベースで書かれてるFWは今すぐ捨てろとここに書き続けるつもりだよ 944 名前：nobodyさん mailto:sage [2007/12/09(日) 15:01:24 ID:???] RoRを設計を参考にしたフレームワークが沢山出ている現状だと、 爆発的に流行することはないと思う。(CakePHPもそうだしね) それにどう頑張ってもRubyは遅い。 945 名前：nobodyさん mailto:sage [2007/12/09(日) 15:26:21 ID:???] Ruby のブロックをPHPに移植してケロ 946 名前：nobodyさん mailto:sage [2007/12/09(日) 15:47:26 ID:???] せめてクロージャでもあればいいんだけどな 947 名前：nobodyさん mailto:sage [2007/12/09(日) 16:40:22 ID:???] ブロック付いて、配列が[]で書けて、配列とハッシュが区別されて、 型が全部オブジェクトになって、組込クラスが整理されて、 オープンクラスになって組込クラスも自由に書き換えられるようになったら PHPで本気出す 948 名前：nobodyさん mailto:sage [2007/12/09(日) 16:57:14 ID:???] それPHPの意味なくね？ 949 名前：nobodyさん mailto:sage [2007/12/09(日) 18:14:30 ID:???] 糞言語でもそこそこ何でもできるので 一度覚えるとそこに安住してしまいがちなのがPHPの最大の欠点だな 950 名前：nobodyさん mailto:sage [2007/12/09(日) 18:52:11 ID:???] HTMLに埋め込めて、$_REQUESTと$_SESSIONがいつでも呼び出せる。これ以上望む物はないよ。 951 名前：nobodyさん mailto:sage [2007/12/09(日) 19:05:19 ID:???] PHPのセッション実装なんてヘッポコじゃないですか 952 名前：nobodyさん mailto:sage [2007/12/09(日) 19:37:21 ID:???] >>942 > PHPはフレームワークじゃなくて、ただのスクリプト言語だからｗ Rubyははフレームワークじゃなくて、ただのスクリプト言語だからｗ で？ 953 名前：nobodyさん mailto:sage [2007/12/09(日) 20:10:57 ID:???] で？ 954 名前：nobodyさん mailto:sage [2007/12/09(日) 20:53:42 ID:???] 　　　　　/ﾆＹﾆヽ  　　　　/（ ﾟ )( ﾟ ）ヽ  　 　／::::⌒｀´⌒::::＼　　　でっていうｗｗｗｗｗｗｗｗ  　　|　,-）＿＿＿（-、|  　　| l　　 |-┬-|　　l |  　　 ＼ 　 `ー'´ 　 ／

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef