PHPでOOP

PHPでOOP (894ﾚｽ)
上下前次 1-新

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がフレームワークのためにあるという主張は初めて聞いた。

上下前次 1-新書関写板覧索設栞歴

あと 488 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.019s