【PHP】フレームワークについて語るスレ10【総合】

1 名前：nobodyさん mailto:sage [2008/02/09(土) 10:43:58 ID:???] 前スレ pc11.2ch.net/test/read.cgi/php/1197383840/ 900 名前：nobodyさん mailto:sage [2008/07/14(月) 21:48:58 ID:???] 当たり前だが使ってる言語だけでOOとか非OOとか言うことはできんわな 901 名前：nobodyさん mailto:sage [2008/07/14(月) 21:58:48 ID:???] >>900 PHPやPerlが一番いい例じゃないかｗ そこまで行くと、何を今更と言ってもいいかと まあ議論の内容は大事だけどね 902 名前：nobodyさん [2008/07/17(木) 01:56:21 ID:r8Tb5l59] 外国語ではフランス語が一番オブジェクト指向に近い 903 名前：nobodyさん mailto:sage [2008/07/17(木) 02:06:39 ID:???] 名詞に性がある言語はOpen Close Principleに反していると思う。反論は認める。 904 名前：nobodyさん mailto:sage [2008/07/17(木) 09:42:03 ID:???] きょうのむずかしいことば「Open Close Principle」 Open Close Principle に一致する日本語のページ 約 55,700 件 www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html Gang of Fourのデザインパターンは，全部で23個ものパターンがあります． オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません． では，なぜ23個もの多くのパターンになってしまったのでしょうか？ このことは，デザインパターンの中に何かかくされた原理というべきものが存在するということを暗示しています． それが今回紹介するOpen-Closed Principleです． Bertrand Meyerによれば，Open-Closed Principleとは次のことを意味します． 「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」 このOpen-Closed Principle -- 「結んでひらいての法則」は，オブジェクト指向設計を考える際，その設計が正しいかどうかの指針を与えてくれるもっとも重要な原理です． >>903 ネタThanksですｗ 参考になりました(^^)v 905 名前：nobodyさん mailto:sage [2008/07/17(木) 13:41:46 ID:???] 理解できたようで理解できていないのがオブジェクト指向 906 名前：nobodyさん mailto:sage [2008/07/17(木) 13:47:12 ID:???] オブジェクト指向すら理解できてない乞食は コンピュータ学園HALでも通っとけ 907 名前：nobodyさん mailto:sage [2008/07/17(木) 20:12:06 ID:???] >>904 > オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません． > では，なぜ23個もの多くのパターンになってしまったのでしょうか？ 数字はたった10個しかないのに、 ものすごくたくさんの数値パターンがあるのと同じ。 文字はたった26文字（アルファベット）しかないのに、 いろんな小説が作られたのと同じ。 人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、 数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。 908 名前：nobodyさん mailto:sage [2008/07/17(木) 20:33:28 ID:???] GoFのパターンがデザインパターンのすべてではないしね。 代表的なものであるのはまちがいないけど。 デザインパターンの重要な点は、有能なプログラマなら意識的 あるいは無意識にやっている、まっとうな設計に名前をつけたこと。 名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。 909 名前：nobodyさん mailto:sage [2008/07/17(木) 23:40:50 ID:???] 実際理解できてない奴大杉 910 名前：nobodyさん [2008/07/18(金) 02:20:52 ID:VtO/mWcS] GoFというネーミングセンスに痛さを感じてしまう。 と思ってたらこれが元ネタ？ ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%83%95%E3%82%A9%E3%83%BC_(%E3%83%90%E3%83%B3%E3%83%89) 911 名前：nobodyさん mailto:sage [2008/07/18(金) 02:33:21 ID:???] その程度で痛いとか言ってたらdankogaiなんてどうなるの？ 912 名前：nobodyさん mailto:sage [2008/07/18(金) 20:21:15 ID:???] PHPのフレームワークはpradoが圧倒的に人気みたいですね q.hatena.ne.jp/1210442237 913 名前：nobodyさん mailto:sage [2008/07/18(金) 20:43:14 ID:???] Pradoってなんだよｗｗｗｗ 914 名前：nobodyさん mailto:sage [2008/07/18(金) 20:47:51 ID:???] これはひどいｗｗｗｗ 915 名前：nobodyさん mailto:sage [2008/07/18(金) 21:11:58 ID:???] pradoはかなり特殊だから信者がこぞって入れたんだろうな 916 名前：nobodyさん mailto:sage [2008/07/18(金) 22:09:19 ID:???] 潔くPHP5だというだけで特殊扱いか。SAXが流行ってた頃を思い出すし、Pradoを俺は嫌いじゃないよ。 917 名前：nobodyさん mailto:sage [2008/07/18(金) 22:37:15 ID:???] いや、PHP5とか好きとか嫌い以前にね。 そのアンケート結果不自然すぎでしょｗ フレームワーク自体の問題じゃなくて 認知度の問題から、その結果はありえないの。 918 名前：nobodyさん mailto:sage [2008/07/18(金) 22:37:45 ID:???] いやPRADOの特殊性はPHP5縛りとかそんなチャチなものじゃなくて もっと恐ろしいというか、どう見てもDelphiですな所。 不作為であの結果はありえないっしょ。 919 名前：nobodyさん [2008/07/18(金) 23:40:48 ID:w/EYto11] 汎用性ではETHNAでしょ 920 名前：nobodyさん mailto:sage [2008/07/22(火) 03:55:09 ID:???] >Mapleは存在をしりませんでした。T-T。これ日本でつくられているのかな。 ワロタｗ 921 名前：nobodyさん mailto:sage [2008/07/23(水) 17:01:32 ID:???] radar.oreilly.com/2008/07/perl-on-app-engine.html GAEにPerlが載ってPHP静かに脂肪ｗｗｗ 922 名前：nobodyさん mailto:sage [2008/07/27(日) 19:58:30 ID:???] 脂肪ネタ、実は好きですｗ 923 名前：nobodyさん mailto:sage [2008/07/30(水) 15:19:27 ID:???] Rails の migration のように、データベースのテーブル定義を複数人で同期させる仕組みって PHP にありますか。 なんかよさそうなライブラリやツールがあれば教えてください。 924 名前：nobodyさん mailto:sage [2008/07/30(水) 19:35:58 ID:???] >>923 俺も知りたいな。 うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、 誰かが書いたVBAマクロでSQLをテキストファイルにしている。 テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。 この辺をフォローしているフレームワークやライブラリってあるのかな？ まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は 感じていないのも事実だけどｗ 925 名前：nobodyさん mailto:sage [2008/07/31(木) 12:29:49 ID:???] >>924 それだとデータは再入力しないといけないよな。それは困る。 データはどうしてるの? 926 名前：nobodyさん mailto:sage [2008/07/31(木) 12:52:20 ID:???] 924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？ カラム名変わってたらちょっと手を入れるけど、 追加とかなら大抵平気だろ。 つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。 開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。 927 名前：924 mailto:sage [2008/07/31(木) 13:24:55 ID:???] >>925 共通で使うデータ（テストデータ・初期データ）はデータファイルとして これもExcelにしておく。INSERT文には自動変換。 データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル 定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、 あくまでドキュメントベースでやってる。 ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ すればいいし。 928 名前：nobodyさん mailto:sage [2008/07/31(木) 14:10:50 ID:???] >>926 >924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？ >カラム名変わってたらちょっと手を入れるけど、 >追加とかなら大抵平気だろ。 それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの? >つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。 >開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。 別にRailsが好きなんて書いてないんだけど。 Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。 なんかRailsに引け目でもあるわけ? >926 929 名前：nobodyさん mailto:sage [2008/07/31(木) 15:16:19 ID:???] スキーマーの変更なんて、そんなに頻繁にするもんじゃないと思うけど。 つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。 930 名前：nobodyさん mailto:sage [2008/07/31(木) 18:57:07 ID:???] ＞それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの? スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。 でもrailsのmigrationも万能じゃないって言うか、 気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので あまりコスト的には変わらない気もするが、、、どうなんだろう。 ＞なんかRailsに引け目でもあるわけ? >926 なんで引け目？ 別にないけど。 ＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。 スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。 でも仕様が固まったあとSQLに置きかえないとやばい。 あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。 それともそういう話ではない？ 931 名前：nobodyさん mailto:sage [2008/08/01(金) 23:30:29 ID:???] >>930 >なんで引け目？ 別にないけど。 だったら最初から >>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。 とか書くなよ。 単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの ほんと役立たずな926

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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