私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレPHPでOOP
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>349
じゃあ貴方がOOPを教えてあげたら?
じゃあ貴方がOOPを教えてあげたら?
>>349
どういう利点があんの?
どういう利点があんの?
クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある?
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある?
ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。
>>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね?
OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。
>>358
概念じゃなく具体的なコードで説明して下さいお願いします。
概念じゃなく具体的なコードで説明して下さいお願いします。
そんなんムリ( ゚Д゚) 本でも読んで勉強して。
今まで読んだ本でOOに関して一番良かったのは Booch法:オブジェクト指向分析と設計 なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。
今まで読んだ本でOOに関して一番良かったのは Booch法:オブジェクト指向分析と設計 なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。
>>336だけど話が広がり過ぎて正直びっくりしてる。
別にOOPしてもいいと思うよ。
俺もクラス使うし。
ただWebプログラミングだとクラス使っただけの手続き型プログラムになりがちだから
OOPの恩恵に与りにくいんじゃないかなーって思っただけ。
たとえば俺はいまPHPでゲーム組んでるんだけど
普通のゲームプログラムとかだと
$char_list[] = new Player();
for($i=0; $i<N; $i++)
{
$char_list[] = new Enemy();
}
while($game_loop)
{
foreach($char_list as $char)
{
$char->Move();
$char->CheckHit();
$char->Draw();
}
}
exit(0);
みたいな感じになるけど
別にOOPしてもいいと思うよ。
俺もクラス使うし。
ただWebプログラミングだとクラス使っただけの手続き型プログラムになりがちだから
OOPの恩恵に与りにくいんじゃないかなーって思っただけ。
たとえば俺はいまPHPでゲーム組んでるんだけど
普通のゲームプログラムとかだと
$char_list[] = new Player();
for($i=0; $i<N; $i++)
{
$char_list[] = new Enemy();
}
while($game_loop)
{
foreach($char_list as $char)
{
$char->Move();
$char->CheckHit();
$char->Draw();
}
}
exit(0);
みたいな感じになるけど
Webプログラミングだと
$buf = DataRead();
$player = new Player();
$player->SetData($buf);
$player->Move();
$player->CheckHit();
$player->Draw();
$buf = $player->GetData();
DataWrite($buf);
exit(0);
みたいなのになりがちじゃん。
それなら
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。
また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。
>モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。
思考を止めてるのは誰だよ。
モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。
あとは自分で本でも読め。
OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。
純粋な議論ではないと思う。
熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか
PHPでOOPの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てOOPになってる
大規模なものをつくるのにOOPじゃないと非効率すぎる
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てOOPになってる
大規模なものをつくるのにOOPじゃないと非効率すぎる
簡単にいうと
規模が小さいほどOOPの必要性が無くなり
規模が大きいほどOOPの必要性がでる
規模が小さいほどOOPの必要性が無くなり
規模が大きいほどOOPの必要性がでる
規模が小さいならスパゲッティコードが最強てこと
大きいならOOPじゃないとはなしにならない
大きいならOOPじゃないとはなしにならない
OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。
あと、規模というよりは複雑さだろうな。
OOPの話は荒れる元だな・・・よし、
~~~~~~~~~ここからOOPネタ禁止~~~~~~~~~~~~~~
~~~~~~~~~ここからOOPネタ禁止~~~~~~~~~~~~~~
(OO)P
↑
マスコット(笑)
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ!
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にw
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう!
↑
マスコット(笑)
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ!
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にw
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう!
思い切って質問してみる。
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?
>>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL
// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CSearch_Personal
// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CUpdate_Personal
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL
// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CSearch_Personal
// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
class CUpdate_Personal
コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな?
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな?
規模と言うか、どれだけ複雑なロジックがあるかだよね。2ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。
テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。
テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す
>>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);
// ここで、データをうけとり、返す。
}
}
設計の仕方は、その人が作ろうとするアプリ次第なので、その人が
やりやすいスタイルでやっていいと思うよ。
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);
// ここで、データをうけとり、返す。
}
}
どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// PostgreSQLへ接続処理などを管理する基底クラス(抽象)
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection
// PostgreSQLへ接続処理などを管理する基底クラス(抽象)
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection
OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を1つのオブジェクトとして設計する。
1つのオブジェクトを、1つのクラスとしてコーディングする。
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を1つのオブジェクトとして設計する。
1つのオブジェクトを、1つのクラスとしてコーディングする。
>>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか
異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル(クラス構造)を考えた
方が良いと思う。
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル(クラス構造)を考えた
方が良いと思う。
>>393
kwsk
kwsk
微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。
とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。
UMLモデリングツールでPHP書いている人いる?
具体的には「Umbrello」を業務で使っている人
具体的には「Umbrello」を業務で使っている人
C#の記事だけど、継承に関するものをみつけた。
Column - 継承を使うべき場合、使うべきではない場合 -
http://www.atmarkit.co.jp/fdotnet/csharp_abc2/csabc2_004/cs2_004_03.html#cs0406
Column - 継承を使うべき場合、使うべきではない場合 -
http://www.atmarkit.co.jp/fdotnet/csharp_abc2/csabc2_004/cs2_004_03.html#cs0406
類似してるかもしれないスレッド
- PHPでPDF (181) - [66%] - 2023/1/14 20:15 ○
- PHP PHPって (73) - [27%] - 2016/1/21 13:46
- PHP4.0とZend (80) - [27%] - 2018/6/27 23:15
トップメニューへ / →のくす牧場書庫について