PHPでOOP
PHPを使ってプログラミングするとき、
プロシージャ指向（手続き型、構造化プログラミング）でもできますが、
オブジェクト指向を使った場合の恩恵を享受するために、
PHPでオブジェクト指向プログラミングの勉強をしてみましょう。
＜目的＞
PHP5でオブジェクト指向プログラミングを行なうための知識を習得する。
（PHP4のOOPもOK、このスレが1000に行く前にPHP6が出たらPHP6のOOPもOK）
＜方向性＞
・このスレは、プログラミング初心者、PHP初心者の勉強の場として利用することを前提にします。
・PHPのOOPの話題に限定します。
（Ruby、Python、Javaなど他言語のOOPについては、その言語のスレッドでお願いします。）
・PHPのOOP学習に役立つ本、WEBサイトの紹介をお願いします。
＜その他＞
・略記は、「OO」＝「オブジェクト指向」、「OOP」＝「オブジェクト指向プログラミング」でお願いします。
・質問をする人はなるべくトリップを付けましょう。
・荒らし、煽り、叩き、気違いは無視・無干渉でお願いします。
このスレで、今日から貴方もOOP！！！＼(^o^)／ こうやってソースを読んでみると、これまで抽象的に聞いていた
フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。
今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと
思ってたけれど、そうでもなく、状況や目的に合わせて選択する
というのが良い事が分かってきたような気がする。
小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、
クラスライブラリを使うスタイルの方が良い場合もありそうだ。 MVCでフレームワークを自作する方向と、クラスライブラリを自作する方向の
２つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、
システムを作る場合の検討材料に出来ると思う。
何でもフルスクラッチしていき、なるべく依存性は無いようにし、（言語の
バージョンくらいに収めるとか）その組み合わせでアプリを作る、みたいな。 再度リファクタしてみました。
ttp://briefcase.yahoo.co.jp/bc/oopfw
[Controlクラス]
・リクエストオブジェクトの参照の重複の削除
・サブクラスでのフックハンドラ処理修正
・Viewオブジェクトの実行方法修正
※これはViewオブジェクトハンドリングの自由度をました反面、
ユーザからの取り回しが煩雑になったかもしれませんね・・
[Modelクラス]
・継承関係の見直し、ItemBaseクラスの導入などです・・
MVCの継承関係が美しくないですが・・
>>291
リファクタしながら構成を練っていってますが
継承クラスでの責任が小さい単位で分割されていると
大きく修正が入った時も楽だと思います。
>>303
MFCもVB6もフックハンドラに処理を記述していく方式なので
それを参考にしています、サンプルFWも自由にいじってもらって
参考にしてもらえたら良いと思います。
>>305クラスライブラリ方式もいいかもしれないですね。 フレームワークのメリットとデメリットにおいて、なるべく具体例を書いた形でまとめてみた。
【メリット】
１．ビューとロジックの切り分けが出来る。（共同作業時に便利）
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs01/aspandvs01_01.html
２．定型的なコードを何度も書かなくてよくなる。
例えば、ASP.NETでは、POSTの値を取得して・・・などの事を考えなくて良い。
テキストボックスやボタンも、画面にドラッグするだけ。
３．ソースコードが自動的にフレームワークの規約に従った記述方法となり、
全体的な処理構成が把握しやすく、メンテナンスが楽になる。
例えば、構造化プログラミングならば、まず全体構成（どの関数がどんな役割を
持っているかなど）を把握し、そこから問題部分を探すことになる。
フレームワークの場合は、まずはこのイベントハンドラの部分を見れば良いなという事が分かる。
【デメリット】
１．フレームワーク自体の使い方を学ばなければならない。
・言語の基本ルールとは異なった、フレームワーク特有の記述方法があるため、すぐに組めない。
ASP.NETでは、IsPostBack の概念を学ばなければならない。
http://www.atmarkit.co.jp/fdotnet/dotnettips/043postback/postback.html
ちいたんでは、function action( &$c )とか、$c->という書き方と機能を把握しなければならない。
http://php.cheetan.net/manual/tutorial.php
・フレームワーク自体にも得手・不得手など特徴があり、それを把握しなければならない。
ASP.NETはIISが必要な為、自動的にサーバOSはWindowsが必須となり、依存性がある。
ASP.NETとStrutsの比較は、以下のサイトを参照
http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_01.html
２．フレームワーク自体に問題があると対処が困難。
例えば.NET Framework のバグは、開発元の不具合修正を待つしかない。
オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。 ＱＡ方式で書いてみた。
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。 何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。 >>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。 >>308
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
>>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。
> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。 修正案
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。 あえてPHP4の構文でやってるのは、PHP4との互換性を保つため？
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。 >>300
>ttp://briefcase.yahoo.co.jp/bc/oopfw
ソースコードを見てビックリ！(・∀・)
コメントが丁寧に書いてあり、OOPを学習する上でとても助かります！
貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m
現時点で、バージョンがOOP_FW_02とOOP_FW_03の２つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。
http://ssurl.net/8vyv
>>281
http://ssurl.net/cp7a
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので） >>321
乙です。m(_ _)m
>>306ですが今後は
・認証の仕組み
・ロギングの仕組み
・エラーハンドリングの仕組み
・バリデイトの仕組み
・トークンの仕組み
・リダイレクトの仕組み
・入力→確認→完了の仕組み
・コアオブジェクトの実行権限の仕組み
など実装していく予定です・・
でも、こればっかりやってるわけにいかないので
気長に見守ってやって下さい。 >>321
乙です。分かりやすくまとまっていますね。
私も少しずつ読んでいって理解しようと思っています。
他のものに比べ、コメントが多いのが助かりますよね。
>>322
読むほうも時間がかかると思いますので、
一気にやらなくていいと思います。（＾＾； MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；
http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11) クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。 OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。 ◎「メンテナンスを行う場合」の比較
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。 >>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。 >>326
・リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。 >同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。 >>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。
>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。 >>330
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。 switchがいらないということは、
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかｗ >>328
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。 BBSの構造化バージョンをうｐしました。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。 そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。
>>336
なんで実行時間とOOの必要性に関連があるの？
>>337
それは了見が狭すぎでしょ。 >>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
>>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。 >>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。 > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。 >>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。
>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。 >>345 訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。 >>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。 > 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
> 指摘にあるように、フローチャートがかけるような処理しかしていないので、
OOPの意味が少ないの理由がおかしい。
フローチャートがかけるような処理しか”貴方が”していないから
必要ないといっているだけであって、そうではないものはOOPの意味がある。
「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。
> 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
> それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
OOPの有効性、そのものがわかってないだけじゃないか？
> 最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
> 各種フレームワークの有用性を確認した方が良いのでは、と感じている。
各種フレームワークは、すべて（といって問題ないレベルで）OOPで
作られていることを知らないの？ >>349
別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。
前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。 クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある？ ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。 >>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね? OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。 >>358
概念じゃなく具体的なコードで説明して下さいお願いします。 そんなんムリ( ﾟДﾟ) 本でも読んで勉強して。
今まで読んだ本でOOに関して一番良かったのは Booch法：オブジェクト指向分析と設計 なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。 勉強したい人が集まってるんだから、必要・不必要で論争しなくても……。 >>336だけど話が広がり過ぎて正直びっくりしてる。
別にOOPしてもいいと思うよ。
俺もクラス使うし。
ただWebプログラミングだとクラス使っただけの手続き型プログラムになりがちだから
OOPの恩恵に与りにくいんじゃないかなーって思っただけ。
たとえば俺はいまPHPでゲーム組んでるんだけど
普通のゲームプログラムとかだと
$char_list[] = new Player();
for($i=0; $i<N; $i++)
{
$char_list[] = new Enemy();
}
while($game_loop)
{
foreach($char_list as $char)
{
$char->Move();
$char->CheckHit();
$char->Draw();
}
}
exit(0);
みたいな感じになるけど
Webプログラミングだと
$buf = DataRead();
$player = new Player();
$player->SetData($buf);
$player->Move();
$player->CheckHit();
$player->Draw();
$buf = $player->GetData();
DataWrite($buf);
exit(0);
みたいなのになりがちじゃん。 それなら
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。 また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。 >>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し
・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム
WEBデザイナがPHP使ったところでSTEP01止まり、
MS OFFICEのマクロ/VBAもそんな感じだね。
ifやforを使わず延々と処理を記述してるのあるよね。
STEP04で思考を止めちゃ駄目なんだ。
勉強の為に「継承」「ポリモーフィズム」を使った
プログラムをあえて書いてみるんだ。
モデリング云々とかそんなの関係ないんだよ。
そもそもここは>>1でしょ？ >モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。 >>367>>368
じゃあモデリング房が設計について判りやすく教えたら？
OOPの概念すら理解出来ない初心者に上流から教えるんですか？
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう？ モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。 >>370
あれれ？モデリングを判りやすく教えてくれるんじゃないんだ？
さては本当は自分も理解して(ry OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。 熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか ＰＨＰでＯＯＰの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てＯＯＰになってる
大規模なものをつくるのにＯＯＰじゃないと非効率すぎる 簡単にいうと
規模が小さいほどＯＯＰの必要性が無くなり
規模が大きいほどＯＯＰの必要性がでる 規模が小さいならスパゲッティコードが最強てこと
大きいならＯＯＰじゃないとはなしにならない OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。 OOPの話は荒れる元だな・・・よし、
〜〜〜〜〜〜〜〜〜ここからOOPネタ禁止〜〜〜〜〜〜〜〜〜〜〜〜〜〜 (ＯＯ)Ｐ
↑
マスコット（笑）
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ！
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にｗ
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう！ 思い切って質問してみる。
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？ >>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL
// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CSearch_Personal
// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CUpdate_Personal コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな？ 規模と言うか、どれだけ複雑なロジックがあるかだよね。２ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。 テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。 テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す >>385
設計の仕方は、その人が作ろうとするアプリ次第なので、その人が
やりやすいスタイルでやっていいと思うよ。
OOPの設計理論は、あくまで一般論なので、必要性を感じないのであれば、
必ずしも守らなくていいだろう。
私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
想定した設計をしただけだよ。
こうやっておけば、書き換えるコードも少なくて済む。
class CSearch_Personal{
// DBを格納する
var $m_db;
// コンストラクタ
function CSearch_Personal(){
$db_info = ""; // ここでDB接続に必要な情報を入れる。
$this->m_db = new CDB_PostgreSQL($db_info);
}
// 電話番号で検索
function Search_by_TEL($tel){
$sql_str = "SELECT * FROM TableA WHERE TEL = '" . $tel . "'";
$this->m_db->Execute($sql_str);
// ここで、データをうけとり、返す。
}
} どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// PostgreSQLへ接続処理などを管理する基底クラス（抽象）
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を１つのオブジェクトとして設計する。
１つのオブジェクトを、１つのクラスとしてコーディングする。 >>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか 異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル（クラス構造）を考えた
方が良いと思う。 >>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね 微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。 とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。 UMLモデリングツールでPHP書いている人いる？
具体的には「Umbrello」を業務で使っている人 >>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。 >>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。 
