Webサイトへのアクセス数の割にDB接続数が異常に多かったのでソース調べてみたらこんな感じでした。
//DBクラス class DB { function __construct(){ //DBコネクション処理 } function query(){ //DBクエリ実行、実行結果を返す } } class hoge { function selectFuga(){ $obj = new DB(); //色々処理... return $obj->query($q); } function updateFuga(){ $obj = new DB(); //色々処理... return $obj->query($q); } function insertFuga(){ $obj = new DB(); //色々処理... return $obj->query($q); } }
使い方ヒント: 「これは臭う」という行を見付けたら、各行のをクリックしてマーキングしておきましょう(要Twitter OAuth認証)
クラス云々より、有限少数で高コストの資源 (DB コネクション) を処理毎に確保しては使い捨ててる、ってのが問題点だよね。 テストケースぐらいなら問題ないけど、扱う規模が大きくなるといろいろ問題 (遅い/性能が出ないとか、セッション数が制限されるとか) が出てくる。
ある命令 (関数やメソッド) によって生じるコスト感がなく字面だけで理解していると、こういうコードを書きがち。 背景を理解して書かないと品質のよいコードは書けないよ、と言うパターンかな。
まあ、背景が変化 (例えばDBコネクションを軽量低コストと仮定) すると、同じコードでも糞コードとはならないわけだが。
抽象化云々というより、nbuyさんの言うとおり、「分かっているかどうか」だと思うけど。
ええとね、抽象化と隠蔽って概念的に違うものだから。
言いたかったのはそっちでござる。
実装の詳細(どのようなデータベースにどのように接続しているか、または、そこから推計されるコストも)を隠すという意味で抽象化とかカプセル化と言た。この場合はカプセル化が正しいの? class DBをclass RFC1149_DBにしてもカプセル化を破壊しないでコストを表示できると思ったから抽象化と言ってしまった。
ごめんなさい。全然文章を読み解けなかったなり。答える気があれば以下をご教示ぷりーず。
自分は、抽象化・隠蔽を「オブジェクト指向でよく使われる単なる一般用語」のつもりで使ってるんだけど、そもそも53135さんと自分の間で、言葉の前提にずれがあるのかな。
それとも、自分の理解力というか、解釈の幅が狭いのかなぁ。。
OOPは建前では、class hoge側はclass DBの具体的な実装に依存しないで公開されたインターフェイスだけを使うんだよみたいなことを主張します。でも、実行時には本音が出て、同じclass hogeの実装に対して、class DB の実装に応じて異なる感想を言ったりします。例えばclass DBは、先週はとりあえずmysql_pconnectだったけど、今日はpg_connectかもしれないし、来週にはそのproxyかもしれないです。インターフェイスはそのままで。
インターフェースやら多態性やらの一般論を聞きたかったわけじゃないんだけどなぁ。。
まあ、いいです。
ジレンマは2つの対立する結論から生じる。建前と本音。一般論と目の前のウンコ。もしかして、nbuyの「背景を理解して書かないと」に賛成で、「背景が変化…する」には不賛成なの?
そりゃそうでしょ。貴方の指摘、このウンコードの趣旨から脱線してるし。
コメント投稿には、twitter認証が必要です。
Twitter認証
クラスの使い方がまだ、うまく理解できていない感じ