PHPでOOP (894ﾚｽ)
上下前次1-新
339: 2008/02/12(火)11:35 ID:??? AAS
>>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
340: 2008/02/12(火)12:57 ID:??? AAS
永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
341(2): 2008/02/12(火)13:17 ID:??? AAS
>>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
342: 2008/02/12(火)13:23 ID:??? AAS
>>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。
343(1): 2008/02/12(火)14:28 ID:??? AAS
> いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ
344(1): 2008/02/12(火)14:34 ID:??? AAS
> そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。
345(1): 2008/02/12(火)14:42 ID:??? AAS
>>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。
>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。
346: 2008/02/12(火)14:50 ID:??? AAS
>>345 訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。
347: に ◆lKs5QMUHoA 2008/02/12(火)18:36 ID:??? AAS
>>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。
348: に ◆lKs5QMUHoA 2008/02/12(火)18:50 ID:??? AAS
確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
省3
349(3): 2008/02/12(火)19:23 ID:??? AAS
> 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
> 指摘にあるように、フローチャートがかけるような処理しかしていないので、
OOPの意味が少ないの理由がおかしい。
フローチャートがかけるような処理しか”貴方が”していないから
必要ないといっているだけであって、そうではないものはOOPの意味がある。
「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。
> 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
> それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
OOPの有効性、そのものがわかってないだけじゃないか？
省4
350: 2008/02/12(火)19:40 ID:??? AAS
>>349
別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。
前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。
351: 2008/02/12(火)19:58 ID:??? AAS
>>349
じゃあ貴方がOOPを教えてあげたら？
352: 2008/02/12(火)20:39 ID:??? AAS
>>349
どういう利点があんの？
353: 2008/02/12(火)22:43 ID:??? AAS
クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある？
354: 2008/02/12(火)22:58 ID:??? AAS
なんで永続性に拘るんだろ。
355: 2008/02/12(火)23:01 ID:??? AAS
なんでオブジェクトに拘るのかってこと。
356(1): 2008/02/12(火)23:08 ID:??? AAS
ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。
357: 2008/02/12(火)23:14 ID:??? AAS
>>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね?
358(1): 2008/02/12(火)23:19 ID:??? AAS
OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。
359: 2008/02/12(火)23:28 ID:??? AAS
>>358
概念じゃなく具体的なコードで説明して下さいお願いします。
360(1): 2008/02/12(火)23:37 ID:??? AAS
そんなんムリ( ﾟДﾟ) 本でも読んで勉強して。
今まで読んだ本でOOに関して一番良かったのは Booch法：オブジェクト指向分析と設計 なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。
361: 2008/02/12(火)23:59 ID:??? AAS
勉強したい人が集まってるんだから、必要・不必要で論争しなくても……。
362: 2008/02/13(水)00:22 ID:??? AAS
>>336だけど話が広がり過ぎて正直びっくりしてる。
別にOOPしてもいいと思うよ。
俺もクラス使うし。
ただWebプログラミングだとクラス使っただけの手続き型プログラムになりがちだから
OOPの恩恵に与りにくいんじゃないかなーって思っただけ。
たとえば俺はいまPHPでゲーム組んでるんだけど
普通のゲームプログラムとかだと
$char_list[] = new Player();
for($i=0; $i<N; $i++)
{
省13
363: 2008/02/13(水)00:22 ID:??? AAS
Webプログラミングだと
$buf = DataRead();
$player = new Player();
$player->SetData($buf);
$player->Move();
$player->CheckHit();
$player->Draw();
省4
364: 2008/02/13(水)00:23 ID:??? AAS
それなら
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
省2
365: 2008/02/13(水)00:42 ID:??? AAS
また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。
366: 2008/02/13(水)09:32 ID:??? AAS
>>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し
・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム
WEBデザイナがPHP使ったところでSTEP01止まり、
省7
367(1): 2008/02/13(水)11:21 ID:??? AAS
>モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。
368(1): 2008/02/13(水)11:29 ID:??? AAS
モデリング無しにOOPで書けるんですか？
369: 2008/02/13(水)11:42 ID:??? AAS
>>367>>368
じゃあモデリング房が設計について判りやすく教えたら？
OOPの概念すら理解出来ない初心者に上流から教えるんですか？
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう？
370(1): 2008/02/13(水)11:50 ID:??? AAS
モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。
371: 2008/02/13(水)11:52 ID:??? AAS
この基地外まだいるのか
372: 2008/02/13(水)12:09 ID:??? AAS
>>370
あれれ？モデリングを判りやすく教えてくれるんじゃないんだ？
さては本当は自分も理解して(ry
373: 2008/02/13(水)12:27 ID:??? AAS
OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。
374: 2008/02/13(水)13:28 ID:??? AAS
熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか
375: 2008/02/13(水)15:14 ID:??? AAS
ＰＨＰでＯＯＰの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てＯＯＰになってる
大規模なものをつくるのにＯＯＰじゃないと非効率すぎる
376: 2008/02/13(水)15:17 ID:??? AAS
簡単にいうと
規模が小さいほどＯＯＰの必要性が無くなり
規模が大きいほどＯＯＰの必要性がでる
377: 2008/02/13(水)15:18 ID:??? AAS
規模が小さいならスパゲッティコードが最強てこと
大きいならＯＯＰじゃないとはなしにならない
378: 2008/02/13(水)15:21 ID:??? AAS
OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。
379: 2008/02/13(水)15:35 ID:??? AAS
OOPの話は荒れる元だな・・・よし、
〜〜〜〜〜〜〜〜〜ここからOOPネタ禁止〜〜〜〜〜〜〜〜〜〜〜〜〜〜
380: 2008/02/13(水)16:30 ID:??? AAS
(ＯＯ)Ｐ
↑
マスコット（笑）
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ！
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にｗ
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう！
381: (ＯＯ)Ｐ 名前はオッピー君。 2008/02/13(水)16:32 ID:??? AAS
おいらに力を・・・・
382: 2008/02/13(水)20:00 ID:??? AAS
どうして荒らしが粘着し始めたのだろう。
383(5): 2008/02/13(水)23:26 ID:yj0olWG5(1) AAS
思い切って質問してみる。
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
384(1): に ◆lKs5QMUHoA 2008/02/13(水)23:56 ID:??? AAS
>>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
省13
385(1): 383 2008/02/14(木)00:16 ID:nkc61sHT(1) AAS
コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな？
386: 2008/02/14(木)03:29 ID:??? AAS
規模と言うか、どれだけ複雑なロジックがあるかだよね。２ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。
387: 2008/02/14(木)03:30 ID:??? AAS
テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。
388: 2008/02/14(木)05:53 ID:??? AAS
テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す
389(2): に ◆lKs5QMUHoA 2008/02/14(木)08:04 ID:??? AAS
>>385
設計の仕方は、その人が作ろうとするアプリ次第なので、その人が
やりやすいスタイルでやっていいと思うよ。
OOPの設計理論は、あくまで一般論なので、必要性を感じないのであれば、
必ずしも守らなくていいだろう。
私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
想定した設計をしただけだよ。
こうやっておけば、書き換えるコードも少なくて済む。
class CSearch_Personal{
// DBを格納する
省13
390(2): に ◆lKs5QMUHoA 2008/02/14(木)08:07 ID:??? AAS
どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// PostgreSQLへ接続処理などを管理する基底クラス（抽象）
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection
391: に ◆lKs5QMUHoA 2008/02/14(木)08:26 ID:??? AAS
OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を１つのオブジェクトとして設計する。
１つのオブジェクトを、１つのクラスとしてコーディングする。
392(1): 2008/02/14(木)08:57 ID:??? AAS
>>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか
393(2): 2008/02/14(木)10:58 ID:??? AAS
異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル（クラス構造）を考えた
方が良いと思う。
394: 2008/02/14(木)11:05 ID:??? AAS
>>393
ｋｗｓｋ
395: 2008/02/14(木)11:09 ID:??? AAS
具体的に聞かれないと、答えようがない。
396: 2008/02/14(木)11:30 ID:??? AAS
>>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね
397(1): 2008/02/14(木)12:00 ID:??? AAS
微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。
398(1): 2008/02/14(木)12:33 ID:??? AAS
とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。
399: 2008/02/14(木)12:59 ID:??? AAS
UMLモデリングツールでPHP書いている人いる？
具体的には「Umbrello」を業務で使っている人
400: 2008/02/14(木)13:18 ID:??? AAS
C#の記事だけど、継承に関するものをみつけた。
Column - 継承を使うべき場合、使うべきではない場合 -
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
401: 2008/02/14(木)14:54 ID:??? AAS
>>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。
402: 2008/02/14(木)15:00 ID:??? AAS
>>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
403: 2008/02/14(木)15:08 ID:??? AAS
>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。
404(2): 2008/02/14(木)15:18 ID:??? AAS
PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。
このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
（というか単純な処理ですむ為のフレームワーク）
OOPにならないことが多い。
だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ？
405: 2008/02/14(木)15:30 ID:??? AAS
>>404
誰に言ってるの？？
406: 2008/02/14(木)15:35 ID:??? AAS
誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。
407(2): 2008/02/14(木)15:36 ID:??? AAS
>>384 も >>389 も >>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう？
// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}
// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}
// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}
// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}
省6
408(3): 2008/02/14(木)15:41 ID:??? AAS
>>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。
あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)
409(1): 2008/02/14(木)15:45 ID:??? AAS
>>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。
410(1): 2008/02/14(木)15:48 ID:??? AAS
>>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。
とか言っておきながら、
> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }
省10
411(1): 2008/02/14(木)15:49 ID:??? AAS
>>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。
412(6): 2008/02/14(木)15:51 ID:??? AAS
>>408-409
まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。
413: 2008/02/14(木)15:53 ID:??? AAS
>>411
一応突っ込み。VBにはクラスがある。（少なくとも5以上）
もちろんnewでインスタンスも生成できる。
414(1): 2008/02/14(木)16:01 ID:??? AAS
>>412
これですかね。
外部ﾘﾝｸ[html]:www.martinfowler.com
細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。
415(1): 412 2008/02/14(木)16:03 ID:??? AAS
>>408
> あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
> SQLを実行できてしまうので、引数で渡すようにしてる。
なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
> (まぁ、staticにしたら引数で渡すしかないけど)
これが理由なら、そのクラスをシングルトンパターンで
実装するという方法もある。
CPersonal::search() などという書き方で呼べるぞ。
ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが（笑）
CakePHPでgetInstance()というメソッドをキーワードにして探せば
省4
416(1): 2008/02/14(木)16:13 ID:??? AAS
>>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。
417: 412 2008/02/14(木)16:13 ID:??? AAS
>>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。
418(1): 412 2008/02/14(木)16:17 ID:??? AAS
>>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ？
それにクラスの変数はグローバル変数じゃないからｗ
419(1): 2008/02/14(木)16:33 ID:??? AAS
>>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。
connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。
420: 2008/02/14(木)17:56 ID:??? AAS
DB周りはZendFrameworkの実装でなんら不満ないなあ。
421(1): 412 2008/02/14(木)18:14 ID:??? AAS
>>419
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。
422(1): 2008/02/14(木)18:51 ID:??? AAS
>>421
例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、
暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、
setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。
423: 2008/02/14(木)19:13 ID:??? AAS
>>422
メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。
そのどっちの例もそのクラスの仕様なんだから。
それを外側から知ろうとか制御しようだなんておかしな話だ。
424(1): 2008/02/14(木)19:41 ID:??? AAS
そもそもstaticも存在しないPHP4で機能をまとめたようなクラス（CDB_PostgreSQLクラスみたいなの）
を作ろうとしてるのが気持ち悪い。
しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない
データベースと相性が悪いのは分かりきったことだろう。
425: 2008/02/14(木)19:54 ID:??? AAS
OOPはデータベースの各要素に関数をくっつけたようなもの？
既存のデータベースはデータを単体でしか扱わない？
だからOOPとデータベースと相性が悪い？
( ﾟДﾟ) ﾜｶﾗﾅｲ
426: 412 2008/02/14(木)20:04 ID:??? AAS
>>424
staticはあくまでstaticだよと明示しているだけで
本質的には必要なものとは思えないけど。便利だけどね。
それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。
たとえば一つのアプリでサーバー負荷分散などで、
複数の接続を使用するときとか、複数のインスタンスが出来る。
427: 2008/02/15(金)07:09 ID:??? AAS
ＰＨＰでもメンバポインタとかつかえれば
インスタンスに縛られない柔軟なＯＯＰができるのにな
428: 2008/02/15(金)17:51 ID:??? AAS
少しだけど、クラス分割のコツが掲載されてたのではっておきます。
VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。
業務Webアプリの作り方の基礎（前編）
業務アプリ開発で失敗しないコツ
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
> 1つの機能（＝たとえWebアプリで複数のページにまたがっていたとしても一連の作業を
> 完了させるまでの一連の操作）に対して、1つのビジネス・ロジック層のクラスを
> 作ってみることをお勧めする。
> 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが
> 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。
省3
429: 2008/02/15(金)20:19 ID:??? AAS
たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う
DRYになってないから直すの大変
430: 2008/02/15(金)22:23 ID:??? AAS
OOPってのは設計的な考え方ってのが含まれるんだけど、
そういう考え方は別として、単にコーディング技法として便利だよ。
431(1): 2008/02/15(金)22:36 ID:??? AAS
>>272
プリミティブだけど実装してみました・・
もはやQuickFormとSmartyがないと動きませんが・・
外部ﾘﾝｸ:briefcase.yahoo.co.jp
432: に ◆lKs5QMUHoA 2008/02/15(金)23:49 ID:??? AAS
風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。
>>392
確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます
ので、is-a関係が正しいですね。
>>407
接続に関して抽象的にクラスを定義するところは勉強になりました。
私はまだまだ継承を使いこなせてないですね。
>>410
> 接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から与える。
この発想は思いつきませんでした。
省1
433: に ◆lKs5QMUHoA 2008/02/15(金)23:50 ID:??? AAS
>>431
サンプルありがとうございます。
あとでソースを読んでみます。
434: 383 2008/02/16(土)00:15 ID:??? AAS
質問しておきながら、反応かなり遅れてしまってごめんなさい。
具体的なコードやアドバイスを提示してくださった方々、ありがとう。
ちょっとまだ、自分には敷居が高くて色々大変そうですが、
考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。
ありがとうございました。
435: 2008/02/16(土)11:47 ID:??? AAS
フレームワークの利点などの検証の参考となるかと思ったので書いておきます。
ASP.NETでは、「検証コントロール」というのが便利そうだ。
「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という
部分の利便性は良く分かる。
ASP.NETで学ぶVisual Studio .NETの魅力
第2回 Visual Studio.NETでプログラム・レス開発を学ぶ（前編）
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。
準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない
もしくは、出来ない場合は、それで終わりみたいな。
省6
436: 2008/02/16(土)12:59 ID:??? AAS
Accessではグリッドが無いけれど、サブフォームで代用する方法はある。
しかし、そのカスタマイズ度は低い。（確か、クリックしたセルの場所を
取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。）
サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような
モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも
VBで0から作り直すのが一般的な選択方法となる。
Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ？
437: 383 2008/02/16(土)17:18 ID:??? AAS
PDOを継承する形でこんなクラスにしてみました。
突っ込みどころ満載だと思うんだけど、とりあえず、このコーディング方法はやめておいたほうがいい、
っていうところを教えていただけると嬉しいです。
class DBConnect(){
// メンバ変数にDB接続情報を記述
function __construct(){} // PDOをインスタンス化
function getConnID(){} // PDOオブジェクト格納変数を返す
}
class TableCtrl extends PDO{} //PDOを継承、汎用関数を定義してもOK.
class CtrlA extends TableCtrl{ // テーブルAを操作する
省3
438(3): 438 2008/02/16(土)17:21 ID:??? AAS
スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、
それを引数にCtrlAをnewする感じ……。
一応動きはするけど……全然ダメだな……。
上下前次1-新書関写板覧索設栞歴
あと 456 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s