PHPでOOP (894ﾚｽ)
上下前次1-新
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
上下前次1-新書関写板覧索設栞歴
あと 494 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s