PHPでOOP

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^)／ 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を一切修正しないですむ。 411 名前：nobodyさん mailto:sage [2008/02/14(木) 15:49:17 ID:???] >>404は、「バージョン6までのVBって構文は構造化だけど、 内部的にはクラスが動いているんだよ」といってるのと 同じ意味のように思える。 誰に何を伝えたいのかは良く分からないが。 412 名前：nobodyさん mailto:sage [2008/02/14(木) 15:51:40 ID:???] >>408-409 まあ、そこは設計しだいでいくつかやり方があるけど、 ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、 クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。 そしてフィールドがプロパティ。 413 名前：nobodyさん mailto:sage [2008/02/14(木) 15:53:27 ID:???] >>411 一応突っ込み。VBにはクラスがある。（少なくとも5以上） もちろんnewでインスタンスも生成できる。 414 名前：nobodyさん mailto:sage [2008/02/14(木) 16:01:23 ID:???] >>412 これですかね。 www.martinfowler.com/eaaCatalog/activeRecord.html 細かいけど、 >そのインスタンスはテーブルのレコードという扱いになる。 なら、searchメソッドは、staticなり外部に置くのではないかと思う。 確かに updateはこの場合 staticにすべきものではないですね。失礼。 415 名前：412 mailto:sage [2008/02/14(木) 16:03:01 ID:???] >>408 > あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも > SQLを実行できてしまうので、引数で渡すようにしてる。 なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、 > (まぁ、staticにしたら引数で渡すしかないけど) これが理由なら、そのクラスをシングルトンパターンで 実装するという方法もある。 CPersonal::search() などという書き方で呼べるぞ。 ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが（笑） CakePHPでgetInstance()というメソッドをキーワードにして探せば 実装例が見つかると思う。 getInstance()関数内のstatic変数に配列[0]にで確保（なぜ？）した後 各メソッドの初めで$_this = getInstance() して$_thisで参照するという・・・ まあ見たほうが早い（？） 416 名前：nobodyさん mailto:sage [2008/02/14(木) 16:13:08 ID:???] >>415 >なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、 DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、 トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが 簡単に見分けられないのは怖いと思うけど。 417 名前：412 mailto:sage [2008/02/14(木) 16:13:24 ID:???] >>414 > なら、searchメソッドは、staticなり外部に置くのではないかと思う。 あー。staticでいいです。単に個人的な環境の理由から PHP4を使っていて忘れていただけです。 418 名前：412 mailto:sage [2008/02/14(木) 16:17:15 ID:???] >>416 でもどっちみちデータベースに操作を出来るところなら、 コネクション知っているわけで、結局同じことでしょ？ それにクラスの変数はグローバル変数じゃないからｗ 419 名前：nobodyさん mailto:sage [2008/02/14(木) 16:33:55 ID:???] >>418 必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、 「データベースに操作できるところ」を限定するという話。 connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、 オブジェクトに対して与えるべきではないだろうということ。 420 名前：nobodyさん mailto:sage [2008/02/14(木) 17:56:06 ID:???] DB周りはZendFrameworkの実装でなんら不満ないなあ。 421 名前：412 mailto:sage [2008/02/14(木) 18:14:31 ID:???] >>419 しかし、テーブルに関するクラスでデータベースを操作しないメソッドって あまりないからなぁ。まあ別にいいけどね。 422 名前：nobodyさん mailto:sage [2008/02/14(木) 18:51:49 ID:???] >>421 例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、 暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、 setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。 423 名前：nobodyさん mailto:sage [2008/02/14(木) 19:13:43 ID:???] >>422 メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。 そのどっちの例もそのクラスの仕様なんだから。 それを外側から知ろうとか制御しようだなんておかしな話だ。 424 名前：nobodyさん mailto:sage [2008/02/14(木) 19:41:54 ID:???] そもそもstaticも存在しないPHP4で機能をまとめたようなクラス（CDB_PostgreSQLクラスみたいなの） を作ろうとしてるのが気持ち悪い。 しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない データベースと相性が悪いのは分かりきったことだろう。 425 名前：nobodyさん mailto:sage [2008/02/14(木) 19:54:36 ID:???] OOPはデータベースの各要素に関数をくっつけたようなもの？ 既存のデータベースはデータを単体でしか扱わない？ だからOOPとデータベースと相性が悪い？ (　ﾟДﾟ) ﾜｶﾗﾅｲ 426 名前：412 mailto:sage [2008/02/14(木) 20:04:12 ID:???] >>424 staticはあくまでstaticだよと明示しているだけで 本質的には必要なものとは思えないけど。便利だけどね。 それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。 たとえば一つのアプリでサーバー負荷分散などで、 複数の接続を使用するときとか、複数のインスタンスが出来る。 427 名前：nobodyさん mailto:sage [2008/02/15(金) 07:09:54 ID:???] ＰＨＰでもメンバポインタとかつかえれば インスタンスに縛られない柔軟なＯＯＰができるのにな 428 名前：nobodyさん mailto:sage [2008/02/15(金) 17:51:58 ID:???] 少しだけど、クラス分割のコツが掲載されてたのではっておきます。 VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。 業務Webアプリの作り方の基礎（前編） 業務アプリ開発で失敗しないコツ www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html > 1つの機能（＝たとえWebアプリで複数のページにまたがっていたとしても一連の作業を > 完了させるまでの一連の操作）に対して、1つのビジネス・ロジック層のクラスを > 作ってみることをお勧めする。 > 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが > 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。 （パフォーマンスを考慮し、） > 可能な限りクラスのインスタンス化が必要ない静的メソッド（Sharedプロシージャ）で > 作成したステートレスな設計にすることをお勧めする。 429 名前：nobodyさん mailto:sage [2008/02/15(金) 20:19:56 ID:???] たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う DRYになってないから直すの大変 430 名前：nobodyさん mailto:sage [2008/02/15(金) 22:23:07 ID:???] OOPってのは設計的な考え方ってのが含まれるんだけど、 そういう考え方は別として、単にコーディング技法として便利だよ。 431 名前：nobodyさん mailto:sage [2008/02/15(金) 22:36:39 ID:???] >>272 プリミティブだけど実装してみました・・ もはやQuickFormとSmartyがないと動きませんが・・ ttp://briefcase.yahoo.co.jp/bc/oopfw 432 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/15(金) 23:49:43 ID:???] 風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。 >>392 確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます ので、is-a関係が正しいですね。 >>407 接続に関して抽象的にクラスを定義するところは勉強になりました。 私はまだまだ継承を使いこなせてないですね。 >>410 > 接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から与える。 この発想は思いつきませんでした。 確かに言われてみるとそうです。CSearch_Personalを一切修正しないで済むようになります。 433 名前：に ◆lKs5QMUHoA mailto:sage [2008/02/15(金) 23:50:26 ID:???] >>431 サンプルありがとうございます。 あとでソースを読んでみます。 434 名前：383 mailto:sage [2008/02/16(土) 00:15:26 ID:???] 質問しておきながら、反応かなり遅れてしまってごめんなさい。 具体的なコードやアドバイスを提示してくださった方々、ありがとう。 ちょっとまだ、自分には敷居が高くて色々大変そうですが、 考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。 ありがとうございました。 435 名前：nobodyさん mailto:sage [2008/02/16(土) 11:47:29 ID:???] フレームワークの利点などの検証の参考となるかと思ったので書いておきます。 ASP.NETでは、「検証コントロール」というのが便利そうだ。 「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という 部分の利便性は良く分かる。 ASP.NETで学ぶVisual Studio .NETの魅力 第2回　Visual Studio.NETでプログラム・レス開発を学ぶ（前編） www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs02/aspandvs02_04.html だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。 準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない もしくは、出来ない場合は、それで終わりみたいな。 話はずれるが、Accessで開発してる時、各種コントロールやウィザードの組み合わせでは 対応出来ないと感じたのを思い出した。ウィザードが準備する通りの物が目的ならば良いのだが、 それにちょっと変更を加えたい場合はどうしたらよいのかという感じ。各種プロパティーの 値を変更してみても変な方向に変わっていくだけ。 自分の意図するようにカスタマイズしたい場合は、非連結のテキストボックスを貼り付けて VBAで制御するスタイルでやってたな。 436 名前：nobodyさん mailto:sage [2008/02/16(土) 12:59:37 ID:???] Accessではグリッドが無いけれど、サブフォームで代用する方法はある。 しかし、そのカスタマイズ度は低い。（確か、クリックしたセルの場所を 取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。） サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも VBで0から作り直すのが一般的な選択方法となる。 Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ？ 437 名前：383 mailto:sage [2008/02/16(土) 17:18:06 ID:???] PDOを継承する形でこんなクラスにしてみました。 突っ込みどころ満載だと思うんだけど、とりあえず、このコーディング方法はやめておいたほうがいい、 っていうところを教えていただけると嬉しいです。 class DBConnect(){ // メンバ変数にDB接続情報を記述 function __construct(){} // PDOをインスタンス化 function getConnID(){} // PDOオブジェクト格納変数を返す } class TableCtrl extends PDO{} //PDOを継承、汎用関数を定義してもOK. class CtrlA extends TableCtrl{ // テーブルAを操作する protected $ConnID; function __construct($ConnID){} //PDOオブジェクト格納変数を渡す } 438 名前：438 mailto:sage [2008/02/16(土) 17:21:28 ID:???] スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、 それを引数にCtrlAをnewする感じ……。 一応動きはするけど……全然ダメだな……。 439 名前：nobodyさん mailto:sage [2008/02/16(土) 17:46:45 ID:???] >>438 なんでもいいけど、既存のフレームワークがどうなっているか見てみろ。 見たら自分で作るきなくなるけどなｗ

---

---

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

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