- 1 名前：1 ◆SWtzLesEmM mailto:age [2007/02/23(金) 13:35:52 ID:???]
- 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^)／
- 310 名前：nobodyさん mailto:sage [2008/02/09(土) 11:25:52 ID:???]
- >>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。
- 311 名前：nobodyさん mailto:sage [2008/02/09(土) 12:20:07 ID:???]
- 書いてみた、とかって適当かつ無責任な
- 312 名前：nobodyさん mailto:sage [2008/02/09(土) 12:23:25 ID:???]
- 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。
- 313 名前：nobodyさん mailto:sage [2008/02/09(土) 12:32:04 ID:???]
- ひょっとして、つられた？
- 314 名前：nobodyさん mailto:sage [2008/02/09(土) 15:20:46 ID:???]
- つんでれた
- 315 名前：nobodyさん mailto:sage [2008/02/09(土) 15:25:19 ID:???]
- >>308
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
- 316 名前：nobodyさん mailto:sage [2008/02/09(土) 15:29:20 ID:???]
- 理解と記憶は別物だと思うけどな。
- 317 名前：nobodyさん mailto:sage [2008/02/09(土) 16:52:42 ID:???]
- >>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。
> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。
- 318 名前：nobodyさん mailto:sage [2008/02/09(土) 17:04:40 ID:???]
- 修正案
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
- 319 名前：nobodyさん mailto:sage [2008/02/09(土) 22:32:17 ID:???]
- あえてPHP4の構文でやってるのは、PHP4との互換性を保つため？
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。
- 320 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/10(日) 03:19:14 ID:???]
- ChStrクラスの件を再開しようかな。
- 321 名前：1 ◆SWtzLesEmM mailto:age [2008/02/10(日) 18:45:04 ID:???]
- >>300
>ttp://briefcase.yahoo.co.jp/bc/oopfw
ソースコードを見てビックリ！(・∀・)
コメントが丁寧に書いてあり、OOPを学習する上でとても助かります！
貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m
現時点で、バージョンがOOP_FW_02とOOP_FW_03の２つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。
ssurl.net/8vyv
>>281
ssurl.net/cp7a
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので）
- 322 名前：nobodyさん mailto:sage [2008/02/10(日) 22:19:07 ID:???]
- >>321
乙です。m(_ _)m
>>306ですが今後は
・認証の仕組み
・ロギングの仕組み
・エラーハンドリングの仕組み
・バリデイトの仕組み
・トークンの仕組み
・リダイレクトの仕組み
・入力→確認→完了の仕組み
・コアオブジェクトの実行権限の仕組み
など実装していく予定です・・
でも、こればっかりやってるわけにいかないので
気長に見守ってやって下さい。
- 323 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/11(月) 02:31:35 ID:???]
- >>321
乙です。分かりやすくまとまっていますね。
私も少しずつ読んでいって理解しようと思っています。
他のものに比べ、コメントが多いのが助かりますよね。
>>322
読むほうも時間がかかると思いますので、
一気にやらなくていいと思います。（＾＾；
- 324 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/11(月) 02:35:18 ID:???]
- MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；
www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11)
- 325 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/11(月) 08:27:05 ID:???]
- クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。
- 326 名前：nobodyさん mailto:sage [2008/02/11(月) 10:26:11 ID:???]
- OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。
- 327 名前：nobodyさん mailto:sage [2008/02/11(月) 10:50:14 ID:???]
- ◎「メンテナンスを行う場合」の比較
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。
- 328 名前：nobodyさん mailto:sage [2008/02/11(月) 10:57:47 ID:???]
- >>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。
- 329 名前：nobodyさん mailto:sage [2008/02/11(月) 12:43:38 ID:???]
- >>326
・リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。
- 330 名前：nobodyさん mailto:sage [2008/02/11(月) 12:53:28 ID:???]
- >同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。
- 331 名前：nobodyさん mailto:sage [2008/02/11(月) 13:07:00 ID:???]
- >>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。
>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。
- 332 名前：nobodyさん mailto:sage [2008/02/11(月) 13:39:48 ID:???]
- >>330
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。
- 333 名前：nobodyさん mailto:sage [2008/02/11(月) 15:01:11 ID:???]
- switchがいらないということは、
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかｗ
- 334 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/11(月) 18:07:43 ID:???]
- >>328
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。
- 335 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/11(月) 18:16:42 ID:???]
- BBSの構造化バージョンをうｐしました。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。
- 336 名前：nobodyさん [2008/02/12(火) 04:15:37 ID:E8FcAvF5]
- そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。
- 337 名前：nobodyさん mailto:sage [2008/02/12(火) 09:16:19 ID:???]
- ここは必要性を語るスレじゃないですよ
- 338 名前：nobodyさん mailto:sage [2008/02/12(火) 10:36:27 ID:???]
- >>336
なんで実行時間とOOの必要性に関連があるの？
>>337
それは了見が狭すぎでしょ。
- 339 名前：nobodyさん mailto:sage [2008/02/12(火) 11:35:52 ID:???]
- >>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
- 340 名前：nobodyさん mailto:sage [2008/02/12(火) 12:57:39 ID:???]
- 永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
- 341 名前：nobodyさん mailto:sage [2008/02/12(火) 13:17:09 ID:???]
- >>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
- 342 名前：nobodyさん mailto:sage [2008/02/12(火) 13:23:42 ID:???]
- >>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。
- 343 名前：nobodyさん mailto:sage [2008/02/12(火) 14:28:33 ID:???]
- > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ
- 344 名前：nobodyさん mailto:sage [2008/02/12(火) 14:34:01 ID:???]
- > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。
- 345 名前：nobodyさん mailto:sage [2008/02/12(火) 14:42:23 ID:???]
- >>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。
>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。
- 346 名前：nobodyさん mailto:sage [2008/02/12(火) 14:50:23 ID:???]
- >>345 訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。
- 347 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/12(火) 18:36:45 ID:???]
- >>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。
- 348 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/12(火) 18:50:13 ID:???]
- 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。
- 349 名前：nobodyさん mailto:sage [2008/02/12(火) 19:23:14 ID:???]
- > 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
> 指摘にあるように、フローチャートがかけるような処理しかしていないので、
OOPの意味が少ないの理由がおかしい。
フローチャートがかけるような処理しか”貴方が”していないから
必要ないといっているだけであって、そうではないものはOOPの意味がある。
「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。
> 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
> それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
OOPの有効性、そのものがわかってないだけじゃないか？
> 最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
> 各種フレームワークの有用性を確認した方が良いのでは、と感じている。
各種フレームワークは、すべて（といって問題ないレベルで）OOPで
作られていることを知らないの？
- 350 名前：nobodyさん mailto:sage [2008/02/12(火) 19:40:22 ID:???]
- >>349
別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。
前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。
- 351 名前：nobodyさん mailto:sage [2008/02/12(火) 19:58:37 ID:???]
- >>349
じゃあ貴方がOOPを教えてあげたら？
- 352 名前：nobodyさん mailto:sage [2008/02/12(火) 20:39:12 ID:???]
- >>349
どういう利点があんの？
- 353 名前：nobodyさん mailto:sage [2008/02/12(火) 22:43:18 ID:???]
- クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある？
- 354 名前：nobodyさん mailto:sage [2008/02/12(火) 22:58:38 ID:???]
- なんで永続性に拘るんだろ。
- 355 名前：nobodyさん mailto:sage [2008/02/12(火) 23:01:04 ID:???]
- なんでオブジェクトに拘るのかってこと。
- 356 名前：nobodyさん mailto:sage [2008/02/12(火) 23:08:25 ID:???]
- ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。
- 357 名前：nobodyさん mailto:sage [2008/02/12(火) 23:14:02 ID:???]
- >>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね?
- 358 名前：nobodyさん mailto:sage [2008/02/12(火) 23:19:02 ID:???]
- OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。
- 359 名前：nobodyさん mailto:sage [2008/02/12(火) 23:28:46 ID:???]
- >>358
概念じゃなく具体的なコードで説明して下さいお願いします。
- 360 名前：nobodyさん mailto:sage [2008/02/12(火) 23:37:53 ID:???]
- そんなんムリ( ﾟДﾟ) 本でも読んで勉強して。
今まで読んだ本でOOに関して一番良かったのは Booch法：オブジェクト指向分析と設計 なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。
- 361 名前：nobodyさん mailto:sage [2008/02/12(火) 23:59:12 ID:???]
- 勉強したい人が集まってるんだから、必要・不必要で論争しなくても……。
- 362 名前：nobodyさん mailto:sage [2008/02/13(水) 00:22:08 ID:???]
- >>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);
みたいな感じになるけど
- 363 名前：nobodyさん mailto:sage [2008/02/13(水) 00:22:41 ID:???]
-
Webプログラミングだと
$buf = DataRead();
$player = new Player();
$player->SetData($buf);
$player->Move();
$player->CheckHit();
$player->Draw();
$buf = $player->GetData();
DataWrite($buf);
exit(0);
みたいなのになりがちじゃん。
- 364 名前：nobodyさん mailto:sage [2008/02/13(水) 00:23:37 ID:???]
- それなら
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。
- 365 名前：nobodyさん mailto:sage [2008/02/13(水) 00:42:03 ID:???]
- また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。
- 366 名前：nobodyさん mailto:sage [2008/02/13(水) 09:32:28 ID:???]
- >>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し
・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム
WEBデザイナがPHP使ったところでSTEP01止まり、
MS OFFICEのマクロ/VBAもそんな感じだね。
ifやforを使わず延々と処理を記述してるのあるよね。
STEP04で思考を止めちゃ駄目なんだ。
勉強の為に「継承」「ポリモーフィズム」を使った
プログラムをあえて書いてみるんだ。
モデリング云々とかそんなの関係ないんだよ。
そもそもここは>>1でしょ？
- 367 名前：nobodyさん mailto:sage [2008/02/13(水) 11:21:35 ID:???]
- >モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。
- 368 名前：nobodyさん mailto:sage [2008/02/13(水) 11:29:38 ID:???]
- モデリング無しにOOPで書けるんですか？
- 369 名前：nobodyさん mailto:sage [2008/02/13(水) 11:42:59 ID:???]
- >>367>>368
じゃあモデリング房が設計について判りやすく教えたら？
OOPの概念すら理解出来ない初心者に上流から教えるんですか？
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう？
- 370 名前：nobodyさん mailto:sage [2008/02/13(水) 11:50:58 ID:???]
- モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。
- 371 名前：nobodyさん mailto:sage [2008/02/13(水) 11:52:02 ID:???]
- この基地外まだいるのか
- 372 名前：nobodyさん mailto:sage [2008/02/13(水) 12:09:17 ID:???]
- >>370
あれれ？モデリングを判りやすく教えてくれるんじゃないんだ？
さては本当は自分も理解して(ry
- 373 名前：nobodyさん mailto:sage [2008/02/13(水) 12:27:30 ID:???]
- OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。
- 374 名前：nobodyさん mailto:sage [2008/02/13(水) 13:28:08 ID:???]
- 熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか
- 375 名前：nobodyさん mailto:sage [2008/02/13(水) 15:14:37 ID:???]
- ＰＨＰでＯＯＰの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てＯＯＰになってる
大規模なものをつくるのにＯＯＰじゃないと非効率すぎる
- 376 名前：nobodyさん mailto:sage [2008/02/13(水) 15:17:14 ID:???]
- 簡単にいうと
規模が小さいほどＯＯＰの必要性が無くなり
規模が大きいほどＯＯＰの必要性がでる
- 377 名前：nobodyさん mailto:sage [2008/02/13(水) 15:18:55 ID:???]
- 規模が小さいならスパゲッティコードが最強てこと
大きいならＯＯＰじゃないとはなしにならない
- 378 名前：nobodyさん mailto:sage [2008/02/13(水) 15:21:38 ID:???]
- OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。
- 379 名前：nobodyさん mailto:sage [2008/02/13(水) 15:35:17 ID:???]
- OOPの話は荒れる元だな・・・よし、
〜〜〜〜〜〜〜〜〜ここからOOPネタ禁止〜〜〜〜〜〜〜〜〜〜〜〜〜〜
- 380 名前：nobodyさん mailto:sage [2008/02/13(水) 16:30:31 ID:???]
- (ＯＯ)Ｐ
↑
マスコット（笑）
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ！
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にｗ
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう！
- 381 名前：(ＯＯ)Ｐ 名前はオッピー君。 mailto:sage [2008/02/13(水) 16:32:38 ID:???]
- おいらに力を・・・・
- 382 名前：nobodyさん mailto:sage [2008/02/13(水) 20:00:42 ID:???]
- どうして荒らしが粘着し始めたのだろう。
- 383 名前：nobodyさん [2008/02/13(水) 23:26:03 ID:yj0olWG5]
- 思い切って質問してみる。
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
- 384 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/13(水) 23:56:35 ID:???]
- >>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL
// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CSearch_Personal
// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CUpdate_Personal
- 385 名前：383 [2008/02/14(木) 00:16:52 ID:nkc61sHT]
- コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな？
- 386 名前：nobodyさん mailto:sage [2008/02/14(木) 03:29:07 ID:???]
- 規模と言うか、どれだけ複雑なロジックがあるかだよね。２ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。
- 387 名前：nobodyさん mailto:sage [2008/02/14(木) 03:30:36 ID:???]
- テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。
- 388 名前：nobodyさん mailto:sage [2008/02/14(木) 05:53:07 ID:???]
- テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す
- 389 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:04:05 ID:???]
- >>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);
// ここで、データをうけとり、返す。
}
}
- 390 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:07:28 ID:???]
- どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// PostgreSQLへ接続処理などを管理する基底クラス（抽象）
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection
- 391 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:26:42 ID:???]
- OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を１つのオブジェクトとして設計する。
１つのオブジェクトを、１つのクラスとしてコーディングする。
- 392 名前：nobodyさん mailto:sage [2008/02/14(木) 08:57:14 ID:???]
- >>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか
- 393 名前：nobodyさん mailto:sage [2008/02/14(木) 10:58:27 ID:???]
- 異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル（クラス構造）を考えた
方が良いと思う。
- 394 名前：nobodyさん mailto:sage [2008/02/14(木) 11:05:10 ID:???]
- >>393
ｋｗｓｋ
- 395 名前：nobodyさん mailto:sage [2008/02/14(木) 11:09:12 ID:???]
- 具体的に聞かれないと、答えようがない。
- 396 名前：nobodyさん mailto:sage [2008/02/14(木) 11:30:06 ID:???]
- >>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね
- 397 名前：nobodyさん mailto:sage [2008/02/14(木) 12:00:13 ID:???]
- 微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。
- 398 名前：nobodyさん mailto:sage [2008/02/14(木) 12:33:45 ID:???]
- とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。
- 399 名前：nobodyさん mailto:sage [2008/02/14(木) 12:59:49 ID:???]
- UMLモデリングツールでPHP書いている人いる？
具体的には「Umbrello」を業務で使っている人
- 400 名前：nobodyさん mailto:sage [2008/02/14(木) 13:18:17 ID:???]
- C#の記事だけど、継承に関するものをみつけた。
Column - 継承を使うべき場合、使うべきではない場合 -
www.atmarkit.co.jp/fdotnet/csharp_abc2/csabc2_004/cs2_004_03.html#cs0406
- 401 名前：nobodyさん mailto:sage [2008/02/14(木) 14:54:28 ID:???]
- >>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。
- 402 名前：nobodyさん mailto:sage [2008/02/14(木) 15:00:26 ID:???]
- >>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
- 403 名前：nobodyさん mailto:sage [2008/02/14(木) 15:08:57 ID:???]
- >>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。
- 404 名前：nobodyさん mailto:sage [2008/02/14(木) 15:18:21 ID:???]
- PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。
このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
（というか単純な処理ですむ為のフレームワーク）
OOPにならないことが多い。
だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ？
- 405 名前：nobodyさん mailto:sage [2008/02/14(木) 15:30:26 ID:???]
- >>404
誰に言ってるの？？
- 406 名前：nobodyさん mailto:sage [2008/02/14(木) 15:35:44 ID:???]
- 誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。
- 407 名前：nobodyさん mailto:sage [2008/02/14(木) 15:36:31 ID:???]
- >>384 も >>389 も >>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう？
// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}
// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}
// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}
// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}
// 個人情報クラス。
class CPersonal extends CTable{
function CSearch($connection) {} //コンストラクタかメソッドでコネクションと接続
function search() {}
function update() {}
}
- 408 名前：nobodyさん mailto:sage [2008/02/14(木) 15:41:23 ID:???]
- >>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。
あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)
- 409 名前：nobodyさん mailto:sage [2008/02/14(木) 15:45:33 ID:???]
- >>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。
- 410 名前：nobodyさん mailto:sage [2008/02/14(木) 15:48:44 ID:???]
- >>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。
とか言っておきながら、
> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }
CSearch_Personalのコンストラクタで
CDB_PostgreSQL決め打ちなのはナンセンス。
DBをPostgreSQLからMySQLへ変換する必要性も生じることを想定した設計というのなら
設計としては、Personalデータを扱う（Search専用？）クラスは
接続するデータベースに依存すべきではない。
（限られた環境だけで動くものを作ればいいだけならどうでもいいが）
接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から
与える。そのときの引数は（PHPに厳密な型は無いが）抽象クラスのCDB_Connection型で与える。
こうすることで、DBをPostgreSQLからMySQLへ変換する必要が生じたとき、
CSearch_Personalを一切修正しないですむ。
|
 |
