>>900
PHPやPerlが一番いい例じゃないかｗ
そこまで行くと、何を今更と言ってもいいかと

まあ議論の内容は大事だけどね

外国語ではフランス語が一番オブジェクト指向に近い

名詞に性がある言語はOpen Close Principleに反していると思う。反論は認める。

きょうのむずかしいことば「Open Close Principle」

Open Close Principle に一致する日本語のページ 約 55,700 件
http://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

理解できたようで理解できていないのがオブジェクト指向

オブジェクト指向すら理解できてない乞食は
コンピュータ学園HALでも通っとけ

>>904
> オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
> では，なぜ23個もの多くのパターンになってしまったのでしょうか？

数字はたった10個しかないのに、
ものすごくたくさんの数値パターンがあるのと同じ。
文字はたった26文字（アルファベット）しかないのに、
いろんな小説が作られたのと同じ。

人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、
数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。

GoFのパターンがデザインパターンのすべてではないしね。
代表的なものであるのはまちがいないけど。

デザインパターンの重要な点は、有能なプログラマなら意識的
あるいは無意識にやっている、まっとうな設計に名前をつけたこと。
名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。

実際理解できてない奴大杉

その程度で痛いとか言ってたらdankogaiなんてどうなるの？

PHPのフレームワークはpradoが圧倒的に人気みたいですね
http://q.hatena.ne.jp/1210442237

Pradoってなんだよｗｗｗｗ

これはひどいｗｗｗｗ

pradoはかなり特殊だから信者がこぞって入れたんだろうな

潔くPHP5だというだけで特殊扱いか。SAXが流行ってた頃を思い出すし、Pradoを俺は嫌いじゃないよ。

いや、PHP5とか好きとか嫌い以前にね。
そのアンケート結果不自然すぎでしょｗ

フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。

いやPRADOの特殊性はPHP5縛りとかそんなチャチなものじゃなくて
もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。

>Mapleは存在をしりませんでした。T-T。これ日本でつくられているのかな。

ワロタｗ

http://radar.oreilly.com/2008/07/perl-on-app-engine.html
GAEにPerlが載ってPHP静かに脂肪ｗｗｗ

脂肪ネタ、実は好きですｗ

Rails の migration のように、データベースのテーブル定義を複数人で同期させる仕組みって PHP にありますか。
なんかよさそうなライブラリやツールがあれば教えてください。

>>923
俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。

この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ

>>924
それだとデータは再入力しないといけないよな。それは困る。
データはどうしてるの?

924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。

つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。

>>925
共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。

データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。

ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。

>>926
>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。

それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?


>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。

別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926

スキーマーの変更なんて、そんなに頻繁にするもんじゃないと思うけど。
つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。

＞それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?

スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。

＞なんかRailsに引け目でもあるわけ? >926

なんで引け目？ 別にないけど。

＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。

スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？

>>930
>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926

どうでもいい

>どうでもいい
君の存在が、ですね

それでいい

っDoctrine

んで、結局どれを使えばいいのカナ？＞フレームワーク

・・・あいやしばらく。
「んなモン、『用途と用件による』に決まってんだろjk」
いや、おっしゃるとおりそのとおり。
でも、向き不向きの議論って、このスレの議論でも結構散発的だったでしょ？
○×△の一覧表なんかあると一応の目安にはなるかなと。
cakeもSymfonyも新しいバージョンになってまだ間もないので、そのあたりもコミでエラい人のご意見をいただければってコトで。

情報源の多いやつを使え。
その過多は各人の環境による。

>>938
多寡だろｗｗｗｗどんだけ低学歴なのよPHPユーザｗｗｗｗｗｗ

たか　―くわ 1 【多寡】
多いことと少ないこと。多いか少ないか。
「金額の―を問わない」

>>939
公式の日本語訳まであるのに、お前は一体なにをやってるんだ

>>943
ちょっと違う

PEAR+Smartyに慣れてるんだが、
それらもサポートしてるフレームワークってあるー？

ethna

>>946
ありがとう。君のおかげで
ネギま買うの思い出したよｗ

>>945
使えないFWって逆にあるの？

ethnaで自作クラスからPEAR呼び出そうとして苦労したあげくFW使うのやめた。

FWのどこでPEAR呼び出しが制限されるんだよｗ