[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 05/09 09:19 / Filesize : 227 KB / Number-of Response : 595
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

PHPでOOP



1 名前:1 ◆SWtzLesEmM mailto:age [2007/02/23(金) 13:35:52 ID:???]
PHPを使ってプログラミングするとき、
プロシージャ指向(手続き型、構造化プログラミング)でもできますが、
オブジェクト指向を使った場合の恩恵を享受するために、
PHPでオブジェクト指向プログラミングの勉強をしてみましょう。

<目的>
PHP5でオブジェクト指向プログラミングを行なうための知識を習得する。
(PHP4のOOPもOK、このスレが1000に行く前にPHP6が出たらPHP6のOOPもOK)

<方向性>
・このスレは、プログラミング初心者、PHP初心者の勉強の場として利用することを前提にします。
・PHPのOOPの話題に限定します。
(Ruby、Python、Javaなど他言語のOOPについては、その言語のスレッドでお願いします。)
・PHPのOOP学習に役立つ本、WEBサイトの紹介をお願いします。

<その他>
・略記は、「OO」=「オブジェクト指向」、「OOP」=「オブジェクト指向プログラミング」でお願いします。
・質問をする人はなるべくトリップを付けましょう。
・荒らし、煽り、叩き、気違いは無視・無干渉でお願いします。

このスレで、今日から貴方もOOP!!!\(^o^)/

364 名前:nobodyさん mailto:sage [2008/02/13(水) 00:23:37 ID:???]
それなら

DataRead();

PlayerMove();
PlayerCheckHit();
PlayerDraw();

DataWrite();

exit(0);

でもいいじゃん的な気がするってだけ。

まぁひとえに俺のプログラミング力不足だと思うけど。

365 名前:nobodyさん mailto:sage [2008/02/13(水) 00:42:03 ID:???]
また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。

そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。

366 名前:nobodyさん mailto:sage [2008/02/13(水) 09:32:28 ID:???]
>>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し

・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム

WEBデザイナがPHP使ったところでSTEP01止まり、
MS OFFICEのマクロ/VBAもそんな感じだね。
ifやforを使わず延々と処理を記述してるのあるよね。

STEP04で思考を止めちゃ駄目なんだ。
勉強の為に「継承」「ポリモーフィズム」を使った
プログラムをあえて書いてみるんだ。

モデリング云々とかそんなの関係ないんだよ。
そもそもここは>>1でしょ?

367 名前:nobodyさん mailto:sage [2008/02/13(水) 11:21:35 ID:???]
>モデリング云々とかそんなの関係ないんだよ。

思考を止めてるのは誰だよ。

368 名前:nobodyさん mailto:sage [2008/02/13(水) 11:29:38 ID:???]
モデリング無しにOOPで書けるんですか?

369 名前:nobodyさん mailto:sage [2008/02/13(水) 11:42:59 ID:???]
>>367>>368
じゃあモデリング房が設計について判りやすく教えたら?

OOPの概念すら理解出来ない初心者に上流から教えるんですか?
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう?

370 名前:nobodyさん mailto:sage [2008/02/13(水) 11:50:58 ID:???]
モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。

371 名前:nobodyさん mailto:sage [2008/02/13(水) 11:52:02 ID:???]
この基地外まだいるのか

372 名前:nobodyさん mailto:sage [2008/02/13(水) 12:09:17 ID:???]
>>370
あれれ?モデリングを判りやすく教えてくれるんじゃないんだ?
さては本当は自分も理解して(ry



373 名前:nobodyさん mailto:sage [2008/02/13(水) 12:27:30 ID:???]
OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。

374 名前:nobodyさん mailto:sage [2008/02/13(水) 13:28:08 ID:???]
熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか

375 名前:nobodyさん mailto:sage [2008/02/13(水) 15:14:37 ID:???]
PHPでOOPの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てOOPになってる
大規模なものをつくるのにOOPじゃないと非効率すぎる

376 名前:nobodyさん mailto:sage [2008/02/13(水) 15:17:14 ID:???]
簡単にいうと
規模が小さいほどOOPの必要性が無くなり
規模が大きいほどOOPの必要性がでる

377 名前:nobodyさん mailto:sage [2008/02/13(水) 15:18:55 ID:???]
規模が小さいならスパゲッティコードが最強てこと
大きいならOOPじゃないとはなしにならない

378 名前:nobodyさん mailto:sage [2008/02/13(水) 15:21:38 ID:???]
OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。

379 名前:nobodyさん mailto:sage [2008/02/13(水) 15:35:17 ID:???]
OOPの話は荒れる元だな・・・よし、



〜〜〜〜〜〜〜〜〜ここからOOPネタ禁止〜〜〜〜〜〜〜〜〜〜〜〜〜〜

380 名前:nobodyさん mailto:sage [2008/02/13(水) 16:30:31 ID:???]
(OO)P

マスコット(笑)

名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ!

最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にw

そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう!

381 名前:(OO)P 名前はオッピー君。 mailto:sage [2008/02/13(水) 16:32:38 ID:???]
おいらに力を・・・・

382 名前:nobodyさん mailto:sage [2008/02/13(水) 20:00:42 ID:???]
どうして荒らしが粘着し始めたのだろう。



383 名前:nobodyさん [2008/02/13(水) 23:26:03 ID:yj0olWG5]
思い切って質問してみる。

テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?

384 名前:◆lKs5QMUHoA mailto:sage [2008/02/13(水) 23:56:35 ID:???]
>>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。

私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。

// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL

// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL

// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CSearch_Personal

// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CUpdate_Personal

385 名前:383 [2008/02/14(木) 00:16:52 ID:nkc61sHT]
コードまで丁寧にありがとう。

クラス設計は、慣れがないと難しいね……。

> このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな?

386 名前:nobodyさん mailto:sage [2008/02/14(木) 03:29:07 ID:???]
規模と言うか、どれだけ複雑なロジックがあるかだよね。2ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。

387 名前:nobodyさん mailto:sage [2008/02/14(木) 03:30:36 ID:???]
テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。

388 名前:nobodyさん mailto:sage [2008/02/14(木) 05:53:07 ID:???]
テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す

389 名前:◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:04:05 ID:???]
>>385
設計の仕方は、その人が作ろうとするアプリ次第なので、その人が
やりやすいスタイルでやっていいと思うよ。
OOPの設計理論は、あくまで一般論なので、必要性を感じないのであれば、
必ずしも守らなくていいだろう。
私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
想定した設計をしただけだよ。
こうやっておけば、書き換えるコードも少なくて済む。

class CSearch_Personal{
// DBを格納する
var $m_db;

// コンストラクタ
function CSearch_Personal(){
$db_info = ""; // ここでDB接続に必要な情報を入れる。
$this->m_db = new CDB_PostgreSQL($db_info);
}

// 電話番号で検索
function Search_by_TEL($tel){
$sql_str = "SELECT * FROM TableA WHERE TEL = '" . $tel . "'";
$this->m_db->Execute($sql_str);
// ここで、データをうけとり、返す。
}
}

390 名前:◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:07:28 ID:???]
どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。

// PostgreSQLへ接続処理などを管理する基底クラス(抽象)
class CDB_PostgreSQL_Connection

// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection

// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection

391 名前:◆lKs5QMUHoA mailto:sage [2008/02/14(木) 08:26:42 ID:???]
OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を1つのオブジェクトとして設計する。
1つのオブジェクトを、1つのクラスとしてコーディングする。

392 名前:nobodyさん mailto:sage [2008/02/14(木) 08:57:14 ID:???]
>>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか



393 名前:nobodyさん mailto:sage [2008/02/14(木) 10:58:27 ID:???]
異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル(クラス構造)を考えた
方が良いと思う。

394 名前:nobodyさん mailto:sage [2008/02/14(木) 11:05:10 ID:???]
>>393
kwsk

395 名前:nobodyさん mailto:sage [2008/02/14(木) 11:09:12 ID:???]
具体的に聞かれないと、答えようがない。

396 名前:nobodyさん mailto:sage [2008/02/14(木) 11:30:06 ID:???]
>>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね

397 名前:nobodyさん mailto:sage [2008/02/14(木) 12:00:13 ID:???]
微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。

ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。

398 名前:nobodyさん mailto:sage [2008/02/14(木) 12:33:45 ID:???]
とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。

個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。

どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。

399 名前:nobodyさん mailto:sage [2008/02/14(木) 12:59:49 ID:???]
UMLモデリングツールでPHP書いている人いる?
具体的には「Umbrello」を業務で使っている人

400 名前:nobodyさん mailto:sage [2008/02/14(木) 13:18:17 ID:???]
C#の記事だけど、継承に関するものをみつけた。
Column - 継承を使うべき場合、使うべきではない場合 -
www.atmarkit.co.jp/fdotnet/csharp_abc2/csabc2_004/cs2_004_03.html#cs0406

401 名前:nobodyさん mailto:sage [2008/02/14(木) 14:54:28 ID:???]
>>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。

402 名前:nobodyさん mailto:sage [2008/02/14(木) 15:00:26 ID:???]
>>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。

> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。




403 名前:nobodyさん mailto:sage [2008/02/14(木) 15:08:57 ID:???]
>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?

処理の負荷というより、決定的な問題がある。

それは主にトランザクションを使ったときに起こる。

複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。

これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。

404 名前:nobodyさん mailto:sage [2008/02/14(木) 15:18:21 ID:???]
PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。

このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
(というか単純な処理ですむ為のフレームワーク)
OOPにならないことが多い。

だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ?

405 名前:nobodyさん mailto:sage [2008/02/14(木) 15:30:26 ID:???]
>>404
誰に言ってるの??

406 名前:nobodyさん mailto:sage [2008/02/14(木) 15:35:44 ID:???]
誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。

407 名前:nobodyさん mailto:sage [2008/02/14(木) 15:36:31 ID:???]
>>384>>389>>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう?

// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}

// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}

// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}

// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}

// 個人情報クラス。
class CPersonal extends CTable{
 function CSearch($connection) {} //コンストラクタかメソッドでコネクションと接続
 function search() {}
 function update() {}
}

408 名前:nobodyさん mailto:sage [2008/02/14(木) 15:41:23 ID:???]
>>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。

あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)

409 名前:nobodyさん mailto:sage [2008/02/14(木) 15:45:33 ID:???]
>>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。

410 名前:nobodyさん mailto:sage [2008/02/14(木) 15:48:44 ID:???]
>>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。

とか言っておきながら、

> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }

CSearch_Personalのコンストラクタで
CDB_PostgreSQL決め打ちなのはナンセンス。


DBをPostgreSQLからMySQLへ変換する必要性も生じることを想定した設計というのなら
設計としては、Personalデータを扱う(Search専用?)クラスは
接続するデータベースに依存すべきではない。
(限られた環境だけで動くものを作ればいいだけならどうでもいいが)

接続オブジェクト(CDB_PostgreSQL)はCSearch_Personalクラス外部から
与える。そのときの引数は(PHPに厳密な型は無いが)抽象クラスのCDB_Connection型で与える。
こうすることで、DBをPostgreSQLからMySQLへ変換する必要が生じたとき、
CSearch_Personalを一切修正しないですむ。

411 名前:nobodyさん mailto:sage [2008/02/14(木) 15:49:17 ID:???]
>>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。

412 名前:nobodyさん mailto:sage [2008/02/14(木) 15:51:40 ID:???]
>>408-409

まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。





413 名前:nobodyさん mailto:sage [2008/02/14(木) 15:53:27 ID:???]
>>411
一応突っ込み。VBにはクラスがある。(少なくとも5以上)
もちろんnewでインスタンスも生成できる。

414 名前:nobodyさん mailto:sage [2008/02/14(木) 16:01:23 ID:???]
>>412
これですかね。
www.martinfowler.com/eaaCatalog/activeRecord.html

細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。


415 名前:412 mailto:sage [2008/02/14(木) 16:03:01 ID:???]
>>408
> あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
> SQLを実行できてしまうので、引数で渡すようにしてる。
なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、

> (まぁ、staticにしたら引数で渡すしかないけど)
これが理由なら、そのクラスをシングルトンパターンで
実装するという方法もある。

CPersonal::search() などという書き方で呼べるぞ。

ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが(笑)
CakePHPでgetInstance()というメソッドをキーワードにして探せば
実装例が見つかると思う。

getInstance()関数内のstatic変数に配列[0]にで確保(なぜ?)した後
各メソッドの初めで$_this = getInstance() して$_thisで参照するという・・・
まあ見たほうが早い(?)

416 名前:nobodyさん mailto:sage [2008/02/14(木) 16:13:08 ID:???]
>>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、

DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。


417 名前:412 mailto:sage [2008/02/14(木) 16:13:24 ID:???]
>>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。

418 名前:412 mailto:sage [2008/02/14(木) 16:17:15 ID:???]
>>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ?

それにクラスの変数はグローバル変数じゃないからw

419 名前:nobodyさん mailto:sage [2008/02/14(木) 16:33:55 ID:???]
>>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。

connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。


420 名前:nobodyさん mailto:sage [2008/02/14(木) 17:56:06 ID:???]
DB周りはZendFrameworkの実装でなんら不満ないなあ。



421 名前:412 mailto:sage [2008/02/14(木) 18:14:31 ID:???]
>>419
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。

422 名前:nobodyさん mailto:sage [2008/02/14(木) 18:51:49 ID:???]
>>421
例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、
暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、
setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。




423 名前:nobodyさん mailto:sage [2008/02/14(木) 19:13:43 ID:???]
>>422
メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。
そのどっちの例もそのクラスの仕様なんだから。
それを外側から知ろうとか制御しようだなんておかしな話だ。


424 名前:nobodyさん mailto:sage [2008/02/14(木) 19:41:54 ID:???]
そもそもstaticも存在しないPHP4で機能をまとめたようなクラス(CDB_PostgreSQLクラスみたいなの)
を作ろうとしてるのが気持ち悪い。

しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない
データベースと相性が悪いのは分かりきったことだろう。

425 名前:nobodyさん mailto:sage [2008/02/14(木) 19:54:36 ID:???]
OOPはデータベースの各要素に関数をくっつけたようなもの?
既存のデータベースはデータを単体でしか扱わない?
だからOOPとデータベースと相性が悪い?

( ゚Д゚) ワカラナイ

426 名前:412 mailto:sage [2008/02/14(木) 20:04:12 ID:???]
>>424
staticはあくまでstaticだよと明示しているだけで
本質的には必要なものとは思えないけど。便利だけどね。

それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。
たとえば一つのアプリでサーバー負荷分散などで、
複数の接続を使用するときとか、複数のインスタンスが出来る。

427 名前:nobodyさん mailto:sage [2008/02/15(金) 07:09:54 ID:???]
PHPでもメンバポインタとかつかえれば
インスタンスに縛られない柔軟なOOPができるのにな

428 名前:nobodyさん mailto:sage [2008/02/15(金) 17:51:58 ID:???]
少しだけど、クラス分割のコツが掲載されてたのではっておきます。
VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。

業務Webアプリの作り方の基礎(前編)
業務アプリ開発で失敗しないコツ
www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html
> 1つの機能(=たとえWebアプリで複数のページにまたがっていたとしても一連の作業を
> 完了させるまでの一連の操作)に対して、1つのビジネス・ロジック層のクラスを
> 作ってみることをお勧めする。

> 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが
> 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。

(パフォーマンスを考慮し、)
> 可能な限りクラスのインスタンス化が必要ない静的メソッド(Sharedプロシージャ)で
> 作成したステートレスな設計にすることをお勧めする。

429 名前:nobodyさん mailto:sage [2008/02/15(金) 20:19:56 ID:???]
たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う
DRYになってないから直すの大変

430 名前:nobodyさん mailto:sage [2008/02/15(金) 22:23:07 ID:???]
OOPってのは設計的な考え方ってのが含まれるんだけど、
そういう考え方は別として、単にコーディング技法として便利だよ。

431 名前:nobodyさん mailto:sage [2008/02/15(金) 22:36:39 ID:???]
>>272
プリミティブだけど実装してみました・・
もはやQuickFormとSmartyがないと動きませんが・・
ttp://briefcase.yahoo.co.jp/bc/oopfw

432 名前:◆lKs5QMUHoA mailto:sage [2008/02/15(金) 23:49:43 ID:???]
風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。

>>392
確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます
ので、is-a関係が正しいですね。

>>407
接続に関して抽象的にクラスを定義するところは勉強になりました。
私はまだまだ継承を使いこなせてないですね。

>>410
> 接続オブジェクト(CDB_PostgreSQL)はCSearch_Personalクラス外部から与える。
この発想は思いつきませんでした。
確かに言われてみるとそうです。CSearch_Personalを一切修正しないで済むようになります。



433 名前:◆lKs5QMUHoA mailto:sage [2008/02/15(金) 23:50:26 ID:???]
>>431
サンプルありがとうございます。
あとでソースを読んでみます。

434 名前:383 mailto:sage [2008/02/16(土) 00:15:26 ID:???]
質問しておきながら、反応かなり遅れてしまってごめんなさい。

具体的なコードやアドバイスを提示してくださった方々、ありがとう。
ちょっとまだ、自分には敷居が高くて色々大変そうですが、
考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。

ありがとうございました。

435 名前:nobodyさん mailto:sage [2008/02/16(土) 11:47:29 ID:???]
フレームワークの利点などの検証の参考となるかと思ったので書いておきます。

ASP.NETでは、「検証コントロール」というのが便利そうだ。
「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という
部分の利便性は良く分かる。

ASP.NETで学ぶVisual Studio .NETの魅力
第2回 Visual Studio.NETでプログラム・レス開発を学ぶ(前編)
www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs02/aspandvs02_04.html

だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。
準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない
もしくは、出来ない場合は、それで終わりみたいな。

話はずれるが、Accessで開発してる時、各種コントロールやウィザードの組み合わせでは
対応出来ないと感じたのを思い出した。ウィザードが準備する通りの物が目的ならば良いのだが、
それにちょっと変更を加えたい場合はどうしたらよいのかという感じ。各種プロパティーの
値を変更してみても変な方向に変わっていくだけ。
自分の意図するようにカスタマイズしたい場合は、非連結のテキストボックスを貼り付けて
VBAで制御するスタイルでやってたな。

436 名前:nobodyさん mailto:sage [2008/02/16(土) 12:59:37 ID:???]
Accessではグリッドが無いけれど、サブフォームで代用する方法はある。
しかし、そのカスタマイズ度は低い。(確か、クリックしたセルの場所を
取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。)
サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような
モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも
VBで0から作り直すのが一般的な選択方法となる。

Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ?

437 名前:383 mailto:sage [2008/02/16(土) 17:18:06 ID:???]
PDOを継承する形でこんなクラスにしてみました。
突っ込みどころ満載だと思うんだけど、とりあえず、このコーディング方法はやめておいたほうがいい、
っていうところを教えていただけると嬉しいです。

class DBConnect(){
// メンバ変数にDB接続情報を記述

function __construct(){} // PDOをインスタンス化
function getConnID(){} // PDOオブジェクト格納変数を返す
}

class TableCtrl extends PDO{} //PDOを継承、汎用関数を定義してもOK.

class CtrlA extends TableCtrl{ // テーブルAを操作する
protected $ConnID;
function __construct($ConnID){} //PDOオブジェクト格納変数を渡す
}

438 名前:438 mailto:sage [2008/02/16(土) 17:21:28 ID:???]
スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、
それを引数にCtrlAをnewする感じ……。
一応動きはするけど……全然ダメだな……。

439 名前:nobodyさん mailto:sage [2008/02/16(土) 17:46:45 ID:???]
>>438
なんでもいいけど、既存のフレームワークがどうなっているか見てみろ。

見たら自分で作るきなくなるけどなw

440 名前:438 mailto:sage [2008/02/17(日) 16:53:21 ID:???]
>>439
返信ありがとう。

まったくわかってないみたいなので、クラスの設計方法から学び直します。

実際の処理をする具象クラスを作って、また別に、それを統括するクラスを作っていく。
複数のクラスを設定によって使い分けしなきゃいけない場合は、抽象クラスなりインターフェイスなりを継承(後者の場合は実装)させて、
メソッド名を統一させた上で、ポリモーフィズム――クラスによって同名メソッドの振る舞いを変えさせるって解釈でいいよね?――で実現させる。
基本こんな感じかな?

プリペアドステートメントに惹かれて、PDOを継承する形で作って見たんだけど、
DB接続関連の場合、接続IDを返してくるmysql_connect(); なんかのほうが、使いやすい気がする。

フレームワーク自作なんて、自分にとってはとんでもない話しですよ……。

441 名前:nobodyさん mailto:sage [2008/02/17(日) 19:14:54 ID:???]
お前の下らない御託はいいから見ろっつの

442 名前:nobodyさん mailto:sage [2008/02/17(日) 20:01:12 ID:???]
>>441
ごめん、無視してたわけじゃないんだ。
とりあえず、軽い「ちいたん」とやらを見てきます。

スレ汚し、ごめんなさい。自重します。



443 名前:nobodyさん mailto:sage [2008/02/17(日) 20:03:55 ID:???]
なぜちいたんを選ぶか・・・


444 名前:nobodyさん mailto:sage [2008/02/17(日) 20:08:23 ID:???]
( ゚д゚)ポカーン

445 名前:nobodyさん mailto:sage [2008/02/17(日) 20:22:12 ID:???]
救いようが無いな。

446 名前:nobodyさん mailto:sage [2008/02/17(日) 21:40:51 ID:???]
スレのレベルを下げちゃってごめんなさい……。

軽い「ちいたん」が入門にはちょうどいいかな、と思っての選択です。
いきなり、CakePHPなど大きいのを見ても、余計に混乱しそうだったので。

スレのレベルを余計に下げるだけなのでROMします。
度重なるスレ汚し、失礼しました。

447 名前:1 ◆SWtzLesEmM mailto:age [2008/02/17(日) 23:11:41 ID:???]
>>324
>>335
掲示板スクリプトの改善、どうもありがとうございます。(*^^*)v

↓動作サンプルを設置しました。

ssurl.net/n777
ssurl.net/ioah

448 名前:nobodyさん mailto:age [2008/02/22(金) 09:37:11 ID:???]
フレームワークをみてみろとアドバイスをしてくださってる方は、
もう少し具体的なアドバイスを出して欲しい。
具体的に、どんなフレームワークの構造を見て、どんなことを
学んだのかなどをあわせて出してくれたら、勉強もしやすいと
思うのですが。

449 名前:nobodyさん mailto:sage [2008/02/22(金) 09:52:27 ID:???]
お前は人に逐一指示されないと何にもできないんだな

450 名前:nobodyさん mailto:sage [2008/02/22(金) 09:59:49 ID:???]
フレームワークはどこに行けば手に入りますか?

451 名前:nobodyさん mailto:sage [2008/02/22(金) 11:02:18 ID:???]
>>449
漠然としすぎていて良く分からないのである程度は具体例が
欲しいという意味なのですが。


>>450
こちらへどうぞ
【PHP】フレームワークについて語るスレ10【総合】
pc11.2ch.net/test/read.cgi/php/1202521438/l50

452 名前:nobodyさん mailto:sage [2008/02/22(金) 11:21:05 ID:???]
>>451
そのくらい自分で探せよという意味なのですが



453 名前:nobodyさん mailto:sage [2008/02/22(金) 11:36:33 ID:???]
>>451
自分でDBの抽象化を考えてみて、クラスの定義だけでも書いてみろ。
その後にZFのZend_DBを見て、自分のとどう違うか、なぜそうなっているのかを考えろ。

それから、偉そうな態度で教えてもらおうと思うな。



454 名前:nobodyさん mailto:sage [2008/02/22(金) 11:50:38 ID:???]
別に偉そうじゃないだろ。
むしろお前のほうが偉そうだ。
何被害妄想してるんだw

455 名前:nobodyさん mailto:sage [2008/02/22(金) 12:50:26 ID:???]
本気でOOP勉強したい人はまずPHP止めないと・・
PHPの世界にOOPの参考になるものがどれほどある?
javaやらずOOP出来ましたってありえないでしょ。

456 名前:nobodyさん mailto:sage [2008/02/22(金) 12:58:24 ID:???]
>>455
OOP勉強するなら、SmallTalkだな。
Javaとかアフォ?w

457 名前:nobodyさん mailto:sage [2008/02/22(金) 13:04:24 ID:???]
本気でOOP勉強する為にPHPをやめる必要は無い。
PHP使いながら、OOP勉強すればいいだけ。

本気でOOP勉強をするなら、非実用的な言語も含めていろいろな
言語を使うことになる。そしてそれらが実用的かというと別の問題。

いくらsmalltalkでOOPをマスターしました!とかいっても
それでウェブサービスを作ることはまずありえないんだから

手段と目的を逆にしないようにね。

458 名前:nobodyさん mailto:age [2008/02/22(金) 13:04:45 ID:???]
その論争は、きりが無いから、マ板とかのOOPのスレでやって欲しい。
「スクリプトの世界ならRubyだろ。」とか、結論が見えてこないし、
このスレの趣旨とは違うと思う。

459 名前:nobodyさん mailto:age [2008/02/22(金) 13:06:38 ID:???]
>>457は非常にすばらしいことを言ったと思う。

460 名前:nobodyさん mailto:sage [2008/02/22(金) 13:13:27 ID:???]
確かにPHPでOOPの解説をしている情報は非常に少ないので、
勉強の際はjavaやC#などの情報を読みながらやることになると思う。
しかし、PHPを辞めるまでする必要性は無いと思う。
言いたいのは「OOPの勉強するのなら、PHPに限定してはいけないよ。」
じゃないの?

461 名前:nobodyさん mailto:sage [2008/02/22(金) 13:16:21 ID:???]
本気で勉強する為にPHPをやめた。
そしてOOPをマスターした。

しかし、Javaでは共有サーバーで動くソフトを作れなかった。
多くのオープンソースアプリはPHP製だった。

OOPをマスターしたが、何も出来なくなった。 完。

462 名前:nobodyさん mailto:sage [2008/02/22(金) 13:27:17 ID:???]
前から思ってたんだが、頭の悪い人間が粘着してるな。
自分がどんな風に思われてるかも分かってないんだろうなw



463 名前:nobodyさん mailto:sage [2008/02/22(金) 13:58:48 ID:???]
>>457
> いくらsmalltalkでOOPをマスターしました!とかいっても
> それでウェブサービスを作ることはまずありえないんだから

今やウエブサービスに欠かせないMVCはそもそもsmalltalkのOOP由来なんだが…。
継続ベースだって覚えておいて損はない。

www.ibm.com/developerworks/opensource/library/os-lightweight8/
www.ibm.com/developerworks/jp/java/library/j-cb07056/index.html

464 名前:nobodyさん mailto:sage [2008/02/22(金) 14:19:47 ID:???]
PHPでOOPする為に別の言語でOOPの勉強をする。
自分の為に必要だからやるだけ。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<227KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef