PHPでOOP

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

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
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。

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

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

ぬこの手ぬこTOP 0.026s