PHPでOOP (894ﾚｽ)
上下前次1-新
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にすべきものではないですね。失礼。
上下前次1-新書関写板覧索設栞歴
あと 480 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s