PHPでOOP
QA方式で書いてみた。
Q:どんな時にフレームワークを使った方がいいの?
・短期間で仕上げなければならない時(この場合はフレームワークの使い方を把握しているのが前提)
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時
Q:フレームワークがあまり向かない場合は?
・個人で小規模アプリを組む時。(一度組んで終わりの場合など)
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。 何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。 >>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。 >>308
> Q:フレームワークがあまり向かない場合は?
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか?
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
>>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか?
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。
> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。 修正案
Q:どんな時にフレームワークを使った方がいいの?
・短期間で仕上げなければならない時(この場合はフレームワークの使い方を把握しているのが前提)
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Q:フレームワークがあまり向かない場合は?
・個人で小規模アプリを組む時。(一度組んで終わりの場合など)
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。 あえてPHP4の構文でやってるのは、PHP4との互換性を保つため?
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。 >>300
>ttp://briefcase.yahoo.co.jp/bc/oopfw
ソースコードを見てビックリ!(・∀・)
コメントが丁寧に書いてあり、OOPを学習する上でとても助かります!
貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m
現時点で、バージョンがOOP_FW_02とOOP_FW_03の2つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。
http://ssurl.net/8vyv
>>281
http://ssurl.net/cp7a
ちょっとずつ読んでますが、全部はまだ理解できないです。(´;ω;`)
レスも参考にしてみます。
(=分からないことでも、検索で調べるときのヒント・手掛かりになるので) >>321
乙です。m(_ _)m
>>306ですが今後は
・認証の仕組み
・ロギングの仕組み
・エラーハンドリングの仕組み
・バリデイトの仕組み
・トークンの仕組み
・リダイレクトの仕組み
・入力→確認→完了の仕組み
・コアオブジェクトの実行権限の仕組み
など実装していく予定です・・
でも、こればっかりやってるわけにいかないので
気長に見守ってやって下さい。 >>321
乙です。分かりやすくまとまっていますね。
私も少しずつ読んでいって理解しようと思っています。
他のものに比べ、コメントが多いのが助かりますよね。
>>322
読むほうも時間がかかると思いますので、
一気にやらなくていいと思います。(^^; MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。(^^;
http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11) クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うpする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。 OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。 ◎「メンテナンスを行う場合」の比較
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
(どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか)
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。 >>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。 >>326
・リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか?
その部分はポリモーフィズムで置き換えられますよ。 >同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。 >>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか?
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。
>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、(このため、すべてがOOPに移項してはいない。)
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。 >>330
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか?
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。 switchがいらないということは、
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかw >>328
(なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。)
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか?」
とか「どんな順番で勉強をしていったら良いですか?」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。 BBSの構造化バージョンをうpしました。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。 そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。
>>336
なんで実行時間とOOの必要性に関連があるの?
>>337
それは了見が狭すぎでしょ。 >>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
>>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数?が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー?って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。 >>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。(っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。 > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。(っていうか大半かも)
どう考えても少数だろw
ロジック無しで何が作れるというんだ?w > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが?
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。 >>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。
>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。 >>345 訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。 >>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない?
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
(PerlやPHPのOOP対応は未だに不十分なところがある)
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも(Webアプリの世界では)OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。 > 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
> 指摘にあるように、フローチャートがかけるような処理しかしていないので、
OOPの意味が少ないの理由がおかしい。
フローチャートがかけるような処理しか”貴方が”していないから
必要ないといっているだけであって、そうではないものはOOPの意味がある。
「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。
> 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
> それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
OOPの有効性、そのものがわかってないだけじゃないか?
> 最近は、どうも(Webアプリの世界では)OOPの有用性を見るよりも、
> 各種フレームワークの有用性を確認した方が良いのでは、と感じている。
各種フレームワークは、すべて(といって問題ないレベルで)OOPで
作られていることを知らないの? >>349
別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。
前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。 クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある? ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。 >>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね? OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。 >>358
概念じゃなく具体的なコードで説明して下さいお願いします。 そんなんムリ( ゚Д゚) 本でも読んで勉強して。
今まで読んだ本で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);
みたいな感じになるけど
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);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。 また Booch法から引用すると 「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことが フラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。 >>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し
・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム
WEBデザイナがPHP使ったところでSTEP01止まり、
MS OFFICEのマクロ/VBAもそんな感じだね。
ifやforを使わず延々と処理を記述してるのあるよね。
STEP04で思考を止めちゃ駄目なんだ。
勉強の為に「継承」「ポリモーフィズム」を使った
プログラムをあえて書いてみるんだ。
モデリング云々とかそんなの関係ないんだよ。
そもそもここは>>1でしょ? >モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。 >>367>>368
じゃあモデリング房が設計について判りやすく教えたら?
OOPの概念すら理解出来ない初心者に上流から教えるんですか?
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう? モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。 >>370
あれれ?モデリングを判りやすく教えてくれるんじゃないんだ?
さては本当は自分も理解して(ry OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。 熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか PHPでOOPの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てOOPになってる
大規模なものをつくるのにOOPじゃないと非効率すぎる 簡単にいうと
規模が小さいほどOOPの必要性が無くなり
規模が大きいほどOOPの必要性がでる 規模が小さいならスパゲッティコードが最強てこと
大きいならOOPじゃないとはなしにならない OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。 OOPの話は荒れる元だな・・・よし、
〜〜〜〜〜〜〜〜〜ここからOOPネタ禁止〜〜〜〜〜〜〜〜〜〜〜〜〜〜 (OO)P
↑
マスコット(笑)
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ!
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にw
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう! 思い切って質問してみる。
テーブル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 コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記2つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな? 規模と言うか、どれだけ複雑なロジックがあるかだよね。2ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。 テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。 テーブルクラスはDBクラスと分けて
テーブルの中から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);
// ここで、データをうけとり、返す。
}
} どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// 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つのクラスとしてコーディングする。 >>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか 異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル(クラス構造)を考えた
方が良いと思う。 >>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね 微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。 とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。 UMLモデリングツールでPHP書いている人いる?
具体的には「Umbrello」を業務で使っている人 >>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。 >>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。 PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。
このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
(というか単純な処理ですむ為のフレームワーク)
OOPにならないことが多い。
だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ? 誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。 >>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() {}
} >>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。
あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど) >>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。 >>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を一切修正しないですむ。 >>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。 >>408-409
まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。
>>411
一応突っ込み。VBにはクラスがある。(少なくとも5以上)
もちろんnewでインスタンスも生成できる。 >>412
これですかね。
http://www.martinfowler.com/eaaCatalog/activeRecord.html
細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。
>>408
> あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
> SQLを実行できてしまうので、引数で渡すようにしてる。
なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
> (まぁ、staticにしたら引数で渡すしかないけど)
これが理由なら、そのクラスをシングルトンパターンで
実装するという方法もある。
CPersonal::search() などという書き方で呼べるぞ。
ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが(笑)
CakePHPでgetInstance()というメソッドをキーワードにして探せば
実装例が見つかると思う。
getInstance()関数内のstatic変数に配列[0]にで確保(なぜ?)した後
各メソッドの初めで$_this = getInstance() して$_thisで参照するという・・・
まあ見たほうが早い(?) >>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。
>>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。 >>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ?
それにクラスの変数はグローバル変数じゃないからw >>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。
connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。
DB周りはZendFrameworkの実装でなんら不満ないなあ。
>>419
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。 >>421
例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、
暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、
setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。
>>422
メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。
そのどっちの例もそのクラスの仕様なんだから。
それを外側から知ろうとか制御しようだなんておかしな話だ。
そもそもstaticも存在しないPHP4で機能をまとめたようなクラス(CDB_PostgreSQLクラスみたいなの)
を作ろうとしてるのが気持ち悪い。
しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない
データベースと相性が悪いのは分かりきったことだろう。 OOPはデータベースの各要素に関数をくっつけたようなもの?
既存のデータベースはデータを単体でしか扱わない?
だからOOPとデータベースと相性が悪い?
( ゚Д゚) ワカラナイ >>424
staticはあくまでstaticだよと明示しているだけで
本質的には必要なものとは思えないけど。便利だけどね。
それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。
たとえば一つのアプリでサーバー負荷分散などで、
複数の接続を使用するときとか、複数のインスタンスが出来る。 PHPでもメンバポインタとかつかえれば
インスタンスに縛られない柔軟なOOPができるのにな 少しだけど、クラス分割のコツが掲載されてたのではっておきます。
VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。
業務Webアプリの作り方の基礎(前編)
業務アプリ開発で失敗しないコツ
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html
> 1つの機能(=たとえWebアプリで複数のページにまたがっていたとしても一連の作業を
> 完了させるまでの一連の操作)に対して、1つのビジネス・ロジック層のクラスを
> 作ってみることをお勧めする。
> 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが
> 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。
(パフォーマンスを考慮し、)
> 可能な限りクラスのインスタンス化が必要ない静的メソッド(Sharedプロシージャ)で
> 作成したステートレスな設計にすることをお勧めする。 たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う
DRYになってないから直すの大変 OOPってのは設計的な考え方ってのが含まれるんだけど、
そういう考え方は別として、単にコーディング技法として便利だよ。 >>272
プリミティブだけど実装してみました・・
もはやQuickFormとSmartyがないと動きませんが・・
ttp://briefcase.yahoo.co.jp/bc/oopfw 風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。
>>392
確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます
ので、is-a関係が正しいですね。
>>407
接続に関して抽象的にクラスを定義するところは勉強になりました。
私はまだまだ継承を使いこなせてないですね。
>>410
> 接続オブジェクト(CDB_PostgreSQL)はCSearch_Personalクラス外部から与える。
この発想は思いつきませんでした。
確かに言われてみるとそうです。CSearch_Personalを一切修正しないで済むようになります。 >>431
サンプルありがとうございます。
あとでソースを読んでみます。 質問しておきながら、反応かなり遅れてしまってごめんなさい。
具体的なコードやアドバイスを提示してくださった方々、ありがとう。
ちょっとまだ、自分には敷居が高くて色々大変そうですが、
考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。
ありがとうございました。 フレームワークの利点などの検証の参考となるかと思ったので書いておきます。
ASP.NETでは、「検証コントロール」というのが便利そうだ。
「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という
部分の利便性は良く分かる。
ASP.NETで学ぶVisual Studio .NETの魅力
第2回 Visual Studio.NETでプログラム・レス開発を学ぶ(前編)
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs02/aspandvs02_04.html
だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。
準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない
もしくは、出来ない場合は、それで終わりみたいな。
話はずれるが、Accessで開発してる時、各種コントロールやウィザードの組み合わせでは
対応出来ないと感じたのを思い出した。ウィザードが準備する通りの物が目的ならば良いのだが、
それにちょっと変更を加えたい場合はどうしたらよいのかという感じ。各種プロパティーの
値を変更してみても変な方向に変わっていくだけ。
自分の意図するようにカスタマイズしたい場合は、非連結のテキストボックスを貼り付けて
VBAで制御するスタイルでやってたな。 Accessではグリッドが無いけれど、サブフォームで代用する方法はある。
しかし、そのカスタマイズ度は低い。(確か、クリックしたセルの場所を
取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。)
サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような
モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも
VBで0から作り直すのが一般的な選択方法となる。
Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ? 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オブジェクト格納変数を渡す
} スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、
それを引数にCtrlAをnewする感じ……。
一応動きはするけど……全然ダメだな……。 >>438
なんでもいいけど、既存のフレームワークがどうなっているか見てみろ。
見たら自分で作るきなくなるけどなw >>439
返信ありがとう。
まったくわかってないみたいなので、クラスの設計方法から学び直します。
実際の処理をする具象クラスを作って、また別に、それを統括するクラスを作っていく。
複数のクラスを設定によって使い分けしなきゃいけない場合は、抽象クラスなりインターフェイスなりを継承(後者の場合は実装)させて、
メソッド名を統一させた上で、ポリモーフィズム――クラスによって同名メソッドの振る舞いを変えさせるって解釈でいいよね?――で実現させる。
基本こんな感じかな?
プリペアドステートメントに惹かれて、PDOを継承する形で作って見たんだけど、
DB接続関連の場合、接続IDを返してくるmysql_connect(); なんかのほうが、使いやすい気がする。
フレームワーク自作なんて、自分にとってはとんでもない話しですよ……。 >>441
ごめん、無視してたわけじゃないんだ。
とりあえず、軽い「ちいたん」とやらを見てきます。
スレ汚し、ごめんなさい。自重します。 スレのレベルを下げちゃってごめんなさい……。
軽い「ちいたん」が入門にはちょうどいいかな、と思っての選択です。
いきなり、CakePHPなど大きいのを見ても、余計に混乱しそうだったので。
スレのレベルを余計に下げるだけなのでROMします。
度重なるスレ汚し、失礼しました。 >>324
>>335
掲示板スクリプトの改善、どうもありがとうございます。(*^^*)v
↓動作サンプルを設置しました。
http://ssurl.net/n777
http://ssurl.net/ioah フレームワークをみてみろとアドバイスをしてくださってる方は、
もう少し具体的なアドバイスを出して欲しい。
具体的に、どんなフレームワークの構造を見て、どんなことを
学んだのかなどをあわせて出してくれたら、勉強もしやすいと
思うのですが。 >>449
漠然としすぎていて良く分からないのである程度は具体例が
欲しいという意味なのですが。
>>450
こちらへどうぞ
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.net/test/read.cgi/php/1202521438/l50 >>451
そのくらい自分で探せよという意味なのですが >>451
自分でDBの抽象化を考えてみて、クラスの定義だけでも書いてみろ。
その後にZFのZend_DBを見て、自分のとどう違うか、なぜそうなっているのかを考えろ。
それから、偉そうな態度で教えてもらおうと思うな。
別に偉そうじゃないだろ。
むしろお前のほうが偉そうだ。
何被害妄想してるんだw 本気でOOP勉強したい人はまずPHP止めないと・・
PHPの世界にOOPの参考になるものがどれほどある?
javaやらずOOP出来ましたってありえないでしょ。 >>455
OOP勉強するなら、SmallTalkだな。
Javaとかアフォ?w 本気でOOP勉強する為にPHPをやめる必要は無い。
PHP使いながら、OOP勉強すればいいだけ。
本気でOOP勉強をするなら、非実用的な言語も含めていろいろな
言語を使うことになる。そしてそれらが実用的かというと別の問題。
いくらsmalltalkでOOPをマスターしました!とかいっても
それでウェブサービスを作ることはまずありえないんだから
手段と目的を逆にしないようにね。 その論争は、きりが無いから、マ板とかのOOPのスレでやって欲しい。
「スクリプトの世界ならRubyだろ。」とか、結論が見えてこないし、
このスレの趣旨とは違うと思う。 確かにPHPでOOPの解説をしている情報は非常に少ないので、
勉強の際はjavaやC#などの情報を読みながらやることになると思う。
しかし、PHPを辞めるまでする必要性は無いと思う。
言いたいのは「OOPの勉強するのなら、PHPに限定してはいけないよ。」
じゃないの? 本気で勉強する為にPHPをやめた。
そしてOOPをマスターした。
しかし、Javaでは共有サーバーで動くソフトを作れなかった。
多くのオープンソースアプリはPHP製だった。
OOPをマスターしたが、何も出来なくなった。 完。 前から思ってたんだが、頭の悪い人間が粘着してるな。
自分がどんな風に思われてるかも分かってないんだろうなw PHPでOOPする為に別の言語でOOPの勉強をする。
自分の為に必要だからやるだけ。 >>463
うん。だからさ勉強・研究の為の言語と
実用・開発の為の言語は別なの。 このソースの解析をがんばればいろいろ見えてくるだろうけど、
一人じゃ到底無理だろうな。別スレでも立てて、解析して
ドキュメント作ろう!見たいなことやってみる?
Visual Studio 2008で見る.NET Frameworkのソースコード
http://www.atmarkit.co.jp/fdotnet/insiderseye/20080222sourcecode/sourcecode.html
> 公開されたソースコードには(もちろん英語だが)多くのコメントが入っており、
> ローカル変数名も元のままの“生”のソースコードである。
> そしてそれがVisual Studio 2008でシームレスにトレースできるようになる >>447
サンプル見たけど
Viewで変数が入らないとこで”を使ってる意味がわからない
”と’の使い方間違ってると思う
面倒な使いわけするならsprintfという手もある
パラメータ変数が渡ってくる
switch文のcaseに頭文字を大文字にしてる意味がわからない
function html_head(){
echo "<html>";
echo "<head><title>BBS</title></head>";
echo "<body>";
}
上は、こうでいいやん!
function html_head(){
echo '<html>';
echo '<head><title>BBS</title></head>';
echo '<body>';
}
なんでダブルクォートやねん >>447
class View_Baseは
helper的な役割だからいいとしても
View_List
View_WriteFinish
コントローラで判断させるべき機能が
Viewで書かれてるし
テンプレート化されてないのもあって
ぐちゃぐちゃですね。
ここがOOP構造を理解しにくい作りになってる
コントローラは面倒でもOOP理解するには必要だ
理解しやすくするためにテンプレート化も必要 >>447
本来コントローラとModelがやりとりする部分が
コントローラが無いために
Viewで処理されてる
MVモデルですね!
OOP構造化理解のためには
面倒でもMVCモデルじゃないと
初心者を間違った方向に導きますよ!!
>>469
具体的にどうすればいいの?
条件分岐してないから切り分けは良さげに見えたんだが。
viewは機能ごとの静的HTML吐くのとは違うの? http://www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/DesMVC.aspx
これの
アクティブモデルは、コントローラとは関係なくモデルで状態が変更される場合に使用されます。
これは別のソースでデータが変更され、この変更をビューに反映する必要がある場合に起こります。
株価相場表示を例に考えてみます。株価データが変更された場合、外部ソースからデータを受け取り、チッカーバンドや警告ウィンドウなどのビューを更新する必要があります。
モデルの内部状態の変更が検知できるのはモデルだけなので、モデルからビューに表示を更新するよう通知する必要があります。
って、hoge.php?param1=aaa¶m2=iiiみたいなリクエストを解析してコントローラがそれに応じたビューを選択して云々
ではなくて、例えばブログだったら記事テーブルにまだ一つもデータが無いときは「まだ記事が登録されていません」のビューをモデルが選ぶ、ってことかい?
だとしたらどうやって実装したらいいんだろ・・・
そのモデルを使用するビューをモデルに登録しておいて、モデルのデータによって分岐させて使うビューを選択。そのときにビューは出力に必要なデータをモデルからひっぱりだす
MSDNは書き方がやたらめんどいぜ コントローラがリクエスト解析
↓
そのリクエストにおいて必要なモデルのインスタンス生成
↓
モデルのメソッド呼び出す
↓
選択したビューのupdate呼びだして出力に必要な変数定義
↓
モデルがビューの出力するメソッドを呼ぶ
ビューはモデルからの変更を受け付けるupdateメソッドと出力するためのputHtmlメソッド持つインターフェイスを実装する
なんか間違ってますか>< 教えてください!>< >>472
それはようするに、株価データのようにユーザーが
ページを更新しなくてもデータが更新されるときの話。
コントローラがモデルからデータ引っ張ってきて
そのデータをビューに渡して表示という処理は変わらない。
↑この処理を、普通は「URLを開いた」というタイミングで行っているわけ。
しかし、そのタイミングだと株価データ表示のようなリアルタイムでの表示は難しい
人間がF5を押す必要がある。この場合も更新されているとは限らず無駄に負荷が高くなる。
それを(ウェブアプリ以外では)モデルからデータが変更されたよーと
コントローラ・ビューに通知し、その通知が来たタイミングでコントローラ・ビューが
モデルからデータを引っ張ってきて(ry)という設計方法がある。
それが>>472で言っていること。
モデルに対して、コントローラやビューを「変更あったら俺に通知してくれ」
登録することでそれを実現する。
(データに変更があったらコントローラ・ビューのこの関数を呼び出してくれとモデルに登録する)
でも、この設計。モデル(つまりサーバー)から変更の通知をすることになるので
ウェブアプリでは一工夫必要になる。結局は、JavaScriptを使って
一定ごとに変更チェックをすることになるわけだが、まあそれをAjaxとかの技術で
非同期的にバックグラウンドで行うことにより、見た目上はサーバーから
変更通知がくるような感じに出来るんでしょ?やったこと無いけど。
その通知を元に、画面の一部、もしくはすべてを再描画する。
あとは詳しい人に任せた。 >>476
レスd
オブザーバパターンはWebアプリに不向きなのかー。
じゃあ、
//コントローラの実行メソッド
public function doExecute(){
if($this->model->getArticleNum() === 0){
$message = '記事がまだ一つもありません';
require_once('./template/Error.php');
}else{
$this->view->putHtml();
}
}
こういう、コントローラがモデルからデータ引っ張ってきて分岐して、ビューを選択する、ってのはアリなのかな?
ちょっとCakePHPとかの資料ググってくるは そういう場合Comet使うんじゃね?
Cometすげえ!って大騒ぎになってたころ資料見ても俺には何がなんだか理解できなかったけど 1を含めてコントローラの役割が全然わかってないんだよ!
MVモデルになってるんだよ!
CakePHP、symfonyのソースをよく解読してみろよ!
1のサンプルにはVIEWにコントローラで処理するコードかいてあるんだぜ! PHPでOOPを追求すると
結局はMVCモデルのフレームワークにテーマが行き着くんだよね
だったらPHPフレームワークのスレと同じじゃんて感じで
ここでOOPを議論するときは
MVCモデル以外を議論の対象にしたいよ >>478
ワロタ。目からうろこw
httpってのはクライアント(ブラウザ側)から聞くことしかできないんだ。
どうやってもサーバーから話しかけることはできない。
だから、たとえば一分おきに、
「データ変わったかい?」「変わってねーよ」
「データ変わったかい?」「変わってねーよ」
「データ変わったかい?」「変わってねーよ」
「データ変わったかい?」「変わってねーよ」
「データ変わったかい?」「変わったよ!」
って聞かないといけない。たとえ4分半の時点でデータが変わっていても
5分後に聞くまでわからない。Cometというのは、
「データ変わったかい?」・・・・・・・・・・・(4分30秒後)「変わったよ!」・・・(数分後)「また変わったよ!」
とこうなる。
本質的にはクライアントから聞いているわけだが、変更があるまで
みのもんたみたいにずっと溜めてから返答するため、
負荷の軽減とリアルタイムな通知が実現できるというわけ。
しかし、いまさらだけどhttpで無茶やりすぎだw >>480
> PHPでOOPを追求すると
> 結局はMVCモデルのフレームワークにテーマが行き着くんだよね
それはPHPに限らず。
そもそもOOPが一番よく使われるのは、フレームワーク部分なんだよ。
OOPはフレームワークを作るときに使うものといっても過言じゃない。
通常のビジネスロジック部分は基本的に単純な命令の集まりになるので
OOPを使っているという感じは無くなる。 >>484
だから結局フレームワークの議論になるんなら
このスレの意味が無いんだよ >>485
フレームワークスレは、フレームワークの比較などを話すスレ
OOPはフレームワークを題材に、OOPの話をするスレ
おk? >>486
class View_List extends View_Base{
//
function Write_HTML_head(){
$this->html_head();
$this->html_title("--- PHP で OOP の BBS ---");
echo "<hr>";
}
// 書き込みフォームを表示させる。
function Write_HTML_form(){
$this->html_form_start("index.php");
echo "<b>[メッセージを投稿する]</b><br>";
$this->html_input_hidden("PAGE", "Write");
echo "タイトル:<br>";
$this->html_input_text("title");
echo "<br>";
echo "メッセージ:<br>";
$this->html_textarea("msg");
echo "<br>";
$this->html_submit(" 書き込む ");
$this->html_form_end();
}
//
function Write_HTML_foot(){
$this->html_foot();
}
//
function Write_HTML_data($line){
echo "<b>タイトル:</b>";
echo $line->GetName();
echo "<br>";
echo "<b>メッセージ:</b>";
echo $line->GetMsg();
echo "<hr>";
}
}
この中のどこがコントローラで判断させるべき処理なんだ? >>487
OOPはフレームワークを題材に、OOPの話をするスレならプログラム板だろ?
初心者だらけの、ここよりも良レスが来ると思うんだが
PHPにこだわる理由がわからない
WEBでのフレームワークならどれも仕組みは同じだろうに
じゃあperlでOOP、rubyでOOPていうスレが無いのは何でなんだ? function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
これは下記がいいだろ?
function GetNextData(){
$ans = "";
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}
return $ans;
} // データを1行読み出す。
function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
変数名の最後に数字使うのは初心者だろ?
もしコード拡張で数値計算が入ったら紛らわしい // データを最後に追記する。
function AddLast($title, $msg){
// ファイルを開く
$hd = fopen($this->m_file_name , "a");
// データを書き込む
$line = $title . $this->m_pause_chr . $msg . "\n";
fwrite($hd, $line);
// ファイルを閉じる
fclose($hd);
}
なんでflock入れないの? $line2 = split($this->m_pause_chr, $line);
はこれの方がわかりやすいだろ?
list($name,$msg) = split($this->m_pause_chr, $line); function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
これは下記に修正した方がわかりやすいよ
function GetNextData(){
$ans = "";
if( $line = fgets($this->m_file_hd, 1024) ){
list($name,$msg) = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($name, $msg);
}
return $ans;
} 変数にオブジェクトが入ってくるなら
初期化はこうだった
function GetNextData(){
$ans = null;
if( $line = fgets($this->m_file_hd, 1024) ){
list($name,$msg) = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($name, $msg);
}
return $ans;
}
else{
$ans = "";
}
これ全部
$ans = null;
に初期化に変えて
elseとっぱらった方がいいよ
返り値はオブジェクトが入ってるか入ってないかという処理なのに
空文字を返すのよくないよ! まぁ空文字もnullも演算子によっては同様にfalse扱いできるという点がPHPの特徴なわけで >>490
> じゃあperlでOOP、rubyでOOPていうスレが無いのは何でなんだ?
人気が無い言語だからw プログラム初心者がPHPだけでOOPを習得するのはほぼ不可能に近いと思う。
OOP習得が目的ならあまりにも無謀だし、全くもって得策ではない。
フレームワークとか利用しても、ユーザが$_POSTとか直接呼べちゃうと
結局OOPの意味が無いんではないだろうか?むしろそれが出来てしまうPHPは
OOP理解には全く向いていない言語だとも思うのだ。
でも不完全ながら、PHPでOOPっぽくコーディングすること自体は楽しいと思う。 >>500
> プログラム初心者がPHPだけでOOPを習得するのはほぼ不可能に近いと思う。
どんな言語でも当たり前。
> フレームワークとか利用しても、ユーザが$_POSTとか直接呼べちゃうと
> 結局OOPの意味が無いんではないだろうか?
まったく関係ない。
PHPでOOPするには
初心者じゃ無理だよ
オブジェクトの設計は上手に出来ても
コーディングレベルで初心者ならではのミスが目立つ PHPでOOP勉強は適してないよ
JAVA,C#,rubyみたいに
OOPを前提として作られた言語じゃないからね
「PHPでOOPは」みたいな話は何度も出てるのに、いつも具体的な話にならないのは何で? 関係なくはないよ。グローバル変数として、どこからでも呼べちゃうんだから、カプセル化できてないってことになる。
だいたい$_REQUESTや$_SESSIONがオブジェクトじゃなくって、変数な時点で、PHPのウェブアプリでオブジェクトなんて使うなっていう、PHP開発者からのメッセージと理解すべき。 グローバル変数が使えたら、カプセル化できない言語ってことになるのか。
そりゃすごい。 俺も、>>469に書いてる、コントローラで判断させるべき処理の具体的な
コードを教えて欲しい。
このコードの話が質問されても出ていないのはなぜ?フレームワークを
使わないと、理論を完全に実現できないとかそういう話だから? >>479=486も結局答えられてないしな。
だめだだめだと言うものの、何故だめなのか、どう書けばいいのかということには答えられない低レベル批判厨なのさ また見えなくすることをカプセル化と勘違いしてる高レベルプログラマさんのお出ましだ >>1 ◆SWtzLesEmM :2007/02/23(金) 13:35:52
このスレも1周年を迎えてましたね!
…時間が経つのは早いなー。><
1年前からあまり進歩してないのは気のせい?(・∀・) >>487
PHPでOOPを勉強するとき、フレームワークは良い見本になりますね!
>>490
>PHPにこだわる理由がわからない
ホームページ作成でPHPの勉強を始めました。
プログラミングの勉強をしていたら、手続き型以外にOOPという方法があることを知り、使えるようになりたいと思いました。
>>502
Zendが積極的に音頭を取って、初心者向けの情報提供をやってくれたらいいですね。><
http://www.zend.co.jp/tech/
Zendの代わりに、PHPプロというサイトがPHP初心者のニーズをカバーしてくれているでしょうか?(・∀・)
http://www.phppro.jp/
>>503
Javaもちょっと勉強してみました。^^
…今使っているレンタルサーバだとJavaが動かない><
>>507
自分で作ったクラスに関しては、クラス内に変数を封じ込めておけるので、スコープ(変数が操作できる領域)をコントロールできるのではないでしょうか?
PHPが最初から用意してくれているグローバル変数($_REQUES等T)のデメリットがよく分からないのですが、いつでもアクセスできるのでこれはこれで便利だと思います。
とりあえず、PHPでOOPが使えるようになりたいです。
PHP以外の言語も使ってみて、必要に応じて使い分けができるようになれればイイですね!(´∀`) フレームワークに関して情報提供どうもありがとうございます。
>>479
MVモデル…(ノ∀`) アチャー
以前作った掲示板を、MVCフレームワークの形で作り直してみました。(^^)v
↓
http://ssurl.net/ryol 結局1のやりたいことは
アマゾンのアフィリエイトの誘導らしいwww >>515
PukiWikiPlusでamazonプラグインをデフォルトのまま使うと、プラグイン作者さん?のアフィリエイトコードが付くようですね。><
ttp://cafelounge.net/dev/?PukiWiki%20Plus!%2FPlng-in%20Customize#a5aa9e2a
>amazonアカウントを設定します。
>define('AMAZON_AID','mikoscafeterr-22');
アフィリエイトはやってませんが、とりあえず本の情報をまとめるのに便利なのでamazonプラグインを使ってみます。^^ >>516
本の情報とかいらんよ
あと、valueclickのアフィリエイトも出てるし
あとTOPページいくとgoogle広告も出てる
結局こういうことかいな
最悪やなお前 具体的な本の紹介をサイトに掲載することは俺は賛成だけどな。
でも、単に羅列してるだけよりも、読んでみてどう思ったのかという
レビューをだして、その人なりの評価を出して欲しいとは思った。
羅列しているだけだと、そのサイト特有の色を感じない。 どう考えても本の紹介を書くのおかしいだろう?
ここだけじゃないけど
技術的なサイトに広告とかマジうざい!!!!
「OOPやるのならば、PHPを辞めた方がいい」といっている人は、
それをいいたいのならば、もっと具体的に言って欲しい。
「RubyはもともとOOPとして設計されている」とか抽象論で終わってるから
何も話が進まず、同じことの繰り返しが続いているんだと思う。
「$_POSTなど、グローバル変数があるからオブジェクト指向的な考えには
ならない」とかそういう話をしてもらえれば、勉強する人はそれを
それぞれに解釈して学んでいけるのではと思う。
「じゃ、辞めようか」と思う人もいれば、「じゃ、その部分だけ気を
つけていけばPHPでもOOPがやれるんだな」と思う人もいるわけで。 >>519
そこまでいいきるのなら、じゃ、みなけりゃいいじゃんとか思うけどな。
あからさまなCMじゃなければいいと思うけどな。俺はこの本をつかって
こういう勉強をして、こういう役に立ったとか、いいじゃん。
このスレは勉強しようっていうスレなんだから。 特に2ちゃんはスレ利用して
最終的に宣伝目的にするやつが多いからな
リンク先に広告があるかどうかだけはシビアに見てる奴が多いよ 100歩譲って本を紹介しても、それは構わないけど
それがアフィリエイトになってるのがおかしいよ 以前、面白いレスを自分のサイトに集めて、面白かったと思う
投稿も受け付けたりしていて、そのサイトに広告を出して儲けてた
人がいて、叩かれたことがあったからな。
あと、のまねこ。
そういう事件があったから、2ちゃんねるをつかって管理者が
儲けようとする目的で広告が掲載されていることにはぴりぴりと
している傾向はあると思うな。
2ちゃんねるを通じて何か企画をするのには賛成だけど、やるのなら
GPLライセンスでやるみたいな意識でやらないとだめなんじゃないかな。 書籍の紹介は良いと思う。そうしないと、@ITの紹介もだめになるわけで、
本当に内容の無いことしかかけなくなってしまう。
情報をまとめていることで、便利だというものもあるしね。
だけど、「アフィリエイトはダメだ」という意見には賛成だ。 1がアフィリエイトするのは構わないけど
2ちゃんを利用するというのが問題あり 2ちゃんねるのスレのまとめサイトであるにもかかわらず、
アフィリエイトされていると、それがどこかで告知されて、
大きく騒がれると思う。このスレに厨を沢山呼ぶことにも
なりかねない。
記念パピコとかが大量に来るので、1は早急にアフィリエイトは
辞めるべきだと思う。 嫌いだと思う事と否定すべき事は分けるものだと思うが、ここでのOOPの議論を見れば
それができないのも仕方がない。 2ちゃん利用して金儲けはよくないし
まとめサイトで書籍紹介するのも始めてみて正直びびった
ご意見どうもありがとうございます。もう少しPHPでOOPの勉強を続けてみます。
>>517
2chでソースコードを投稿(>>36-50)したら、>>53さんが「わかりにくいからWebサイトにまとめてくれ。」とアドバイスしてくれました。
とりあえず、無料サーバ(XREA)にまとめサイトを設置しましたが、XREAは広告を表示するようになっているので仕方ないですね。
ttp://www.xrea.com/?action=ad
>当サイトは、無料運営のため、広告コードを自分で挿入する、または、自動的に挿入して頂く必要があります。
>>521
アドバイスどうもありがとうございます。
PukiWikiPlusのamazonプラグインに付いていたプラグイン作者さん?のアフィリエイトコードは外しました。
>>526
CGM型のサイトを運営して収益が出る場合、運営者だけが利益を得て、参加者に利益が還元されないと、不公平=不満に感じる人もいるかもしれませんね。
このまとめサイトは、ソースコード置き場+自分のメモという感じで使っていますが、利益が出せるでしょうか?
営利目的の企画として行なうなら、企業や出版社等に運営してもらった方が、本格的になっていいかもしれませんね。(^^;
…どこかで「PHPでOOP」講座を作ってもらえないでしょうか?>PHPプロさんとか?
>>527
勉強するとき、本を読む人っていますよね?
本は読まない人もいると思いますが、本の情報も調べたのでついでにまとめました。 1の目的がよくわらん。
1がコテハン使ってスレをリードするのおかしいやろ?
まとめサイトも1が作るのちゃうやろ
名無しがやることやろ
1がスレをリードせんといて
長くレスが続くなら
それは本当に需要のあるスレであって
1が作り上げたスレになってるやん >>533
1(個人)に利益が出てたら、必ず騒ぐ人が出てくる。
しかし、利益が出てなければ、その旨を断っておけば、
騒いでいる意見は無視しておけば、しばらくすれば蒸発
すると思う。 >>534
俺は1ではないが。
> 1の目的がよくわらん。
スレタイの通り。PHPでOOPを勉強する。
> 1がコテハン使ってスレをリードするのおかしいやろ?
何がおかしいのかがわからん。
こうあるべきだとかいうガイドラインでもあるわけ?
> まとめサイトも1が作るのちゃうやろ
> 名無しがやることやろ
お前のローカルルールを押し付けるな。
1がまとめサイトやめたら変わりにお前がやるのか? >>535
お前のやりたいことの方が分からん。
変な哲学押し付けるな。 スレ主がまとめサイト作ってるスレてあるの?
広告目的以外に見たことないんだけどwww >>539
だったら君が利用しなきゃいいだけでは? WebProg板で
スレ主がまとめサイト作ってるスレどこにあるんだよ? 2ちゃんにふさわしくない行動は見て見ぬふりは出来んよ 1は需要のないスレを無理に上げるのやめて欲しいよ
自分の存在を認められたいだけのオナニスレだよ アフィリエイト見てオナニスレてことに確信がもてたよ
このスレは1の自己満足以外に何も生まれないよ結果としてね >>543-544
何で君はスルーができないの?
誰も書き込まなければそのまま消えていくんじゃないの? コテハン使って自慢げにソースコード公開するやつは
よほど腕に自信がある奴か
初心者相手に自己満足したい奴かのどっちか >>545
君の語りを見てオナニレスてことに確信がもてたよ
これらのレスは君の自己満足以外に何も生まれないよ結果としてね >>547
ああ、そうか。だったら君はもう来るな。 >>550
俺は1じゃないんだけどな。言い返せなくてそれしかいえないんだな。
それにお前がここに常駐する意味はないよな。 さ あ 、 も り あ が っ
て
ま
い
り
ま
し
た 1が書き込みしないと
恐ろしいほどさびれてんねw
1だけがPHPでOOPに興味があって
その興味を無理矢理に広めようとしてる
このスレの落胆ぶり見ればよくわかるwww PHPにかぎらず、「オブジェクト指向」が一般化したと言っても、実際にはライブラリ(フレームワークを含む)が
クラス化されて、プログラマはそれを使ってるという程度の話でしかないから、OOPそのものの話が盛り
上がらないのは、当然といえば当然。 WebProgで勢いあるのなんてくだすれぐらいだろ 何度も1のこと前向きにとらえようとしたけど
やはり1が何をしたいのかよくわからん 自称非営利団体の運営を本業に転換する難しさのバーチャル体験学習。
乗せられたボランティアからの不満が噴出。
ありがち。そして解散。ありがち。 私も1が必死にスレ継続させてる意味が???
営利団体なら意味はわかりますが このスレ1年以上在るのに、 1 ◆SWtzLesEmM が書き込んだことがある日数って 16日だよ。
必死どころか、やる気があるのかと言いたい。
2007
02/23 02/24 02/27 02/28 05/12
06/12 07/06 07/11 07/26
2008
01/29 02/02 02/06 02/10 02/17
02/24 02/25
まー、ここで勉強するな、とは言わないけど、本気でやろうと思ってる人は、まず自分で本買うなりして勉強すると思うよ。
別に興味ないやつはスルーでも何でもしときゃいいと思う。 このスレで、今日から貴方もOOP!!!\(^o^)/
>>1
オッパッピーの間違いですよね スレタイの主旨からずれるけど、
やはりC言語は、一度は学んでいた方が良いな。
Javaからプログラムに入ったから、PHPのOOPでアロー演算子使うのにとても違和感あったのだけど、
Cの構造体を知って、ドットシンタックスよりアロー演算子の方が正統派と思えるようになった。 諸事情により、Web系のプログラミングから離れていたけれど、
また時間がとれたら舞い戻ってきます。よろしくw PHPに触る機会が・・・なんで、VBばっかりなんだ・・・ クラスの作り方(設計)について、考え方が参考になる本がありました。
http://www.amazon.co.jp/dp/4798110558/
モデルとプロセスをめぐる冒険
「モデリング」ということについて調べてみると、いろいろノウハウがあるようです。 大手ECサイトのヨドバシドットコムが、サイトリニューアルから大規模な障害を3日間...
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php?qid=1220150877
506 :目のつけ所が名無しさん:2008/10/26(日) 00:47:20
大手ECサイトで、ここまで派手なリリース失敗は初めて見た。
エンジニア向けIT情報誌や関連サイトは、ぜひ取材して原因を明かして欲し
いは。
定期的に保守してるの誰?
糞スレに対してその執念が怖いんだが。。。
PHP でオブジェクト指向の設計をするための 7 つの良い習慣を身につける
http://www.ibm.com/developerworks/jp/opensource/library/os-php-7oohabits/
PHP での適切な OO の習慣を身につけることによって、より安定していて、保守が容易で、拡張も容易にできるアプリケーションを作成することができます。そのためには、次のことを忘れないでください。
* 控え目である
* 良き隣人である
* メドゥーサを見ないようにする
* 結びつきを極力弱くする
* 結束性を高める
* 家族の一員として扱う
* パターンで考える
こうした習慣を身につけ、使いこなせるようになると、皆さんはきっとアプリケーションの品質が変わったことに驚くはずです。 内容は否定しないが、その書き方はどうかなと思うな。
英語の翻訳だからなのかな。
「メドゥーサを見ないようにする」なんて飛躍した比喩表現では
イメージつかないだろw >>589
メデューサの項目でインタフェースを使う意義って何?
ファクトリーパターンの利点しか説明してないような気がするんだが >>591
広告の方が多いってどうなんだよ
1:4で広告じゃねーか
オブジェクト指向のカンタンな例
<?php
class A
{
function foo()
{
echo 'hello <br>';
}
}
$a = new A();
$a->foo();
$b=new A();
$b->foo();
?> 簡易なMVCモデルのサンプルってないのかなぁ。
フレームワークを作るとか、フレームワークを使うとかじゃなくてさ。
考え方を学ぶためにみてみたいんだけど。
過去ログにあるように、つい、MVモデルになってしまうもんで。 Googleで、
簡易なMVCモデル
と検索させる
ttp://www.google.com/search?client=safari&rls=ja-jp&q=簡易なMVCモデル&ie=UTF-8&oe=UTF-8
ドゾ... 結構前の話だけど、>>488-489へのレスってついてるのかな?
過去ログ読み直してみても、何処が批判されているのかが分からん。
Viewはこれでいいと思うのだが。 http://www.zend.co.jp/tech/index.php?cmd=read&page=%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0%BB%D8%BF%CB%2F%A3%B4%A1%A5MVC
ひょっとして、「Viewではhtml出力をしてはいけない」という考えを示している
ということなのか?
html出力は別のクラスに任せるべきで、Viewはそのクラスのインスタンスの生成
と実行までを行うべきだという視点で批判してるとか。 >>601
批判している書込みは>>479です。
「に」のサンプルが、(コーディングにかかわるルール以外で)
MVCの設計はこれで良いのかがあいまいなまま終わってる気がします。 気になってる批判は>>469もだな。そして>>471となっているが、そのレスが
無くておわってないかい? よくわかんないんだけど、OOPとMVCって両立できるの? これどうなの?
ttp://www13.plala.or.jp/naka_jima/php/chapter12.html MVCだと必ずフレームワークを使わなければならないわけでもないよね。ちがうの?
それとも、非常に単純なクラス構成でMVCを実現しようという考えが間違いとか? >>606見たんだけど、MVCってこんななの?
View や Model 1つに対して1ファイルみたいだけど、ファイル量半端ないことになりそう。 DBの形式や最終的な見せ方によって、ファイル数は変わるんじゃないの?
でも、MVCってわりとファイル多めだよな!
1ファイルのコード量、大して多くないけど ファイルが多めなのが嫌なら1ファイル内に複数書けばいいじゃない OOPそのものをやろうとするとクラスやファイル量が多くなるからね。
汎用性を考えて作ろうとするとなおさらだ。それはしかたがないのかも。
そこをあえて、フレームワークや外部のモジュールなどを使わずに
非常にクラス数を少なくしてやってみたいなと思うんだけどね。
MVCの理解の一環として。 <?php
class Framework{
// コントローラー
public function controller(array $inp){
$model = $this->model($this->di('Action', $this->di('Action_Mapper',$inp));
$this->view($model);
}
// モデル
protected function model(Action $actions){
return $action->do();
}
// ビュー
protected function view($model){
print ($this->di('View_Helper', array($model));
}
// DIコンテナ
protected function di($class, $options){
return new $class($options);
}
}
class HelloWorld extends Frameworkd{}
App::controller($_GET); せめてクラスは3つ以上にするべきだろ。
最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで
出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく
なると思うんだけど。 これはMVCどこがやるのが妥当か?
ってところで迷う。
時々、曖昧なのが出てきちゃう。 >>619
ここで事例を通じて具体的な意見を交わしていけばどうかな?」
例えば・・・
掲示板
■コントローラ:処理の内容を判断するクラス
・プログラムが実行された時、一番最初に実行される
・POSTの値をみて、以下の処理にてどれに該当するかを判断する
・データを表示する
・データを書込む
・編集用のフォームを表示する
■ビュー:htmlのレイアウト表示を担当するクラス
・以下のメソッドを持つ
・データをhtmlで表示する
・データ編集用htmlを表記する
■モデル:データファイルを管理するクラス
・ファイルの読み込み、書込みをする
・外部とは1件分のデータはBBSLineクラスでやりとりする >>620
『■コントローラ:処理の内容を判断するクラス 』の
> ・データを表示する
> ・データを書込む
『 ■モデル:データファイルを管理するクラス 』の
> ・ファイルの読み込み、書込みをする
って、意味が重複しているような感じがするのですが...
ならば、
■コントローラ:処理の内容を判断するクラス
・モデルからデータを受け取る
・モデルにデータを渡す
とかでは、おかしいですか? >>621
>>620じゃないけど。
・データを表示する
・データを書込む
・編集用のフォームを表示する
実際に上記の作業をするのは View と Model だよ。Controllerがするわけじゃない。
コントローラーはどれがリクエストされたかを判断して、適切な Model と View を呼び出す。 >>469は具体的に何処のコードを批判しているのかが分からないので
どなたか解説を頼みます。 MVCモデルでM同士で連携することってあり?
それとも必ずC経由?
C経由の場合、Mをなるべく疎結合になるように細分化してると、
Cの各Actionに書くロジック量が半端なく多くなってくるんだよね。
(Aデータを取ってきてBデータを取ってきてBをCバリデータに通してAとBを基にDを作成して・・・みたいな)
一つのAction内にロジックが増えるのもどうかと思うし、それって新しいモデルじゃんという気もしてこないでもない。 >>624
俺はM同士で連携するかたちでも良いと思うけどね。
CからMを見た場合、あるまとまった処理単位でメソッドを呼び出す形であることが
重要だと思うから。
CがMを使うときは必ずメソッドA呼び出してメソッドB、メソッドCを実行しなければならない。
さらに、そういう3連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが
悪くなると思うから。 試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。
>624
変化する内部状態を持つモデル同士で連携させると見通しが悪くなる。
生成してから、(観察される)内部状態が変化しないようなモデルはどこから呼んでもそれほど大きな問題はない。
オブジェクトの生成期間中に(観察される)内部状態が変化するようなモデルは、C直轄にしといた方がいい。 生成期間→生存期間
なんか寝ぼけてた。
要は変化する「状態」を持っているもの全てはCの管理下に置いておいた方がいいってこった。
「状態」が無いもの(生成時にファイルからデータをロードしてそれっきり、とか)はどこにあったって構わない。
インスタンスの生成を行なうクラスは自分ルールでもいいからある程度絞っておかないと混乱すると思うけどな。 変な質問だけど、OOP での Validator ってのがよくわかんねえ。
is_numeric(); とかをModel内にべた書きしないで、Validatorオブジェクトを通じて、変数の内容を確認すればいいの?
$str = 'string';
$valid =& new Validator();
$valid->isStr($string);
みたいな感じで。
BaseValidator みたいな基本的なチェックをするクラスを作って、継承した先で複雑なチェック用のメソッドを実装させればいいのかな。 引数間違えてる。最後の行。
$valid->isStr($str);
ね。まぁ、別に問題ないが。 >630
ttp://gist.github.com/38261
俺はValidatorクラスはコントローラ単位で実装してる。「入力値の検証」なのだから、コントローラの責任。
Validatorだけ独立させるのはコードの見通しを良くするためであり、責任はあくまでコントローラにある。
ただ、実際にそっからコールするのはModelのメソッド。何が許可されるかを知ってるのはだいたいModelだからな。
たとえば受け付ける値が日付なら、そっから日付クラスのvalidateメソッドを呼び出す(MyDate::validate($string))。
POSTされる中に列挙型(<select>から送られるような、選択肢が限られているもの)とかがあった場合にこの構成は滅茶苦茶強い。
<select>のためのデータ生成とか、送られたvalueから画面表示用の文字列(「〜モード」とか)への変換を一箇所に集められる。
あと、文字列が決まったフォーマットになっているか調べる場合とかな。
is_strとかctype_stringとかstrlenだけで検証が終わるものはvalidatorクラス内に直書きする。
validateNumericとかvalidateStrとか書くよりその方が分かりやすい。 >>633
ものすごく丁寧にありがとう。
まだぼんやりとしかわからないけど、サンプルコードを読み解いて、いろいろ試してみる。 >>633
>「入力値の検証」なのだから、コントローラの責任。
「検証する」んじゃなく「検証させる」のが仕事じゃないの?
ここでいう入力値の検証って例えばどんなこと言ってる?
3行目で
>何が許可されるかを知ってるのはだいたいModelだからな。
って書いてるってことは、なにか、Modelに関係ないものを想定してると思うんだけど。
>635
大雑把に言うと、処理を始める前に可能なパラメータの検証全般。
純粋に入力値だけを見て判定できるものだな。システムや環境の状態を見なくとも判定できるエラーを出す役割。
処理を始めないと分からないもの(DBに指定されたエントリーがあるかとか)は、バリデーションでは扱わない。
DBにこの値があった場合はクッキーにこれが無いといけない…みたいなのも対象外。
日付として「'9999-12-31'」が指定されてもバリデーションでは引っ掛けない。これは有効な入力。
「'2008-13-45'」はバリデーションでエラーとして引っ掛ける。この日付が有効になる事はあり得ないから。
メールアドレスが正しいフォーマットかをチェックするのはバリデーションで、それが有効なメールアドレスかをチェックするのはモデル。
ユーザーIDとして正しいフォーマットならばバリデーションは通るが、当該ユーザーがいない場合モデルがエラーを出す。 >>636
なんとなく分かるけど、
例えばそれだと「2008-13-45は日付(のつもり)」ってことを
コントローラが知っとかないといけないってことだよね?
あと、日付が必要なくなった、とかいうときは
コントローラーを変更しないといけないってことにならない?
なんか拘ってるようでアレだけどお勉強スレってことで許してw
って、もしかして、リクエストとして渡ってくるものを想定してるのかな。
hoge.php?date=20081231
とか。
>637
「コントローラ」の指している範囲が俺と違う気がする。
俺はディスパッチャ(処理の振り分け)部分じゃなくて、そこから振り分けられる先のコントローラを指している。
ぐぐったが、「アクション」としてクラスにして丸ごとコントローラから切り離す文化圏もあるようだな。
「日付のつもりで送られてくる文字列がある」という事実は、ディスパッチャは(たいていの場合)知らない。
が、コントローラ(アクション)は知っている。だって知らないと日付具象モデルに処理を引き渡しようがないからな。
Cにはどの道変更が入る。リクエストをモデルに引き渡すのが仕事だからな。
「日付がどこからどう渡ってくるか」はCの管轄であってMじゃない。Mはそれを知っていてはいけない。
Mは「日付を渡されたらどうする」だけ知っていればよく、実際問題どこに日付があるかはCが隠蔽すべき。
たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
「省略時は日付を無視して過去のレコードを全取得する」という場合は、データ取得ロジックが変更なのでまずMは変わる。
制御の構造、呼び出しインターフェイスも変わるのでCも変わる。 まあ実際は、日付省略時のMの挙動を変えるだろうけどな。
>638
入力値以外のもの(DB内の値とか処理結果)の検証は当然モデル。
というか、そういうのは一般にはバリデーションとは言わずアサーションと呼ぶ。 >>639
Cは振り分けだけが仕事だと思ってたんだけど。
その先にさらに C があることなんてあるのか。
サブコントローラーみたいな感じ? >641
やっぱ、そこか。
例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。
で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。
で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。
これをMVCのうち、MとCのどっちに置くかの問題。
MVC、MVCって言ってるけど、本質的には4層なんだよ。
処理の振り分けに1層を割くならば、4層なくてはならない。
処理の振り分け=呼び出すCの決定(ディスパッチャ)→どのMを呼び出すかを制御する(コントロール)
→データを実際に扱う(モデル)→表示(ビュー)、となる。
実際のフレームワークだと、RailsやZendはDispatcherが振り分けを担当し、制御はコントローラが執っている。
(だから、おまいの目から見れば、コントローラは仕事をやりすぎに見えるはず)
SymfonyやCakeだとControllerがディスパッチを担当し、制御はActionが執っている。
CodeIgniterだとディスパッチは単一のエントリポイント(リクエストを受けるphpファイル)であるindex.phpが行なって、制御はCが行なっている。 >>642
>たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
>この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
これって制御じゃなくてロジックだからモデル的仕事じゃねぇの? >>642
横槍で質問してすまんかった。
すげーわかりやすい。
勉強になった。ありがとう。 >>645
あなたの顔に死相が出ていますよ。4層だけに。 考え方としてディスパッチとコントロールは分けるべきだが、
実装するときは、コントロールで括るよな? >647
M・V・Cで分けるならCってのは同意。いちおう
> 処理の振り分けに1層を割くならば
と予防線は張ってあるわけだが。
俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。 >>648
> Controllerの親クラスとかControllerFactoryでディスパッチする事が多い
ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの? 手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。 勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。
自作のモチベ下がっちまったい。 もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい 元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。
で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。
凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして0から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな?w
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるw まぁ、たぶんそんな感じ。
要するにフレームワークの魅力に気付いたわけですよ。 そういうのは簡単に気づけないだろう。
プログラムは体感して分かっていくものなのだから。 俺としては魅力に気付けただけでも大きな進歩だ。
自作云々は別にして。 では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ?
PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。 いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る >>662 ≠ >>667
だからね。
俺は人に語れるほどまだ理解してないから。 サポートするといってるんだから、教えてじゃないだろw ttp://q.hatena.ne.jp/1188498291 >>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの
メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。 Java とか C#やったほうが飲み込みは早くなるのかな。
でも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。 >>680
いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。
なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな?ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。 ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。
ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。 >>683
それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。 PHP では OOP を学べないという意見があるが、結論だけ
いうのではなく、その理由の部分を述べていくといいかもね。 ん、どこかにPHPでは学べないと書いてあるのかな?
個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。 オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。 出る幕はあると思うが、最終的にフレームワークを構築することになると思う。
いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。
また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。 WEBアプリでもActionScript3なら、バリバリOOPだYO! まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。 >>691
エンタープライズならそんなケースいくらでもあるだろw >>689
俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。 >>693
ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが >>692
聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。 クライアントマシンの性能がこれだけアップしているのに、
クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかw ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって
性能うんぬんは考えてないんだよな 勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい 699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前:nobodyさん[sage] 投稿日:2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう >>698
性能を求めるならフレームワークなんて使うなって話 >>698が言ってる「性能」って何?
これは釣りなのか? 「やあ、とりあえず性能の一番いいやつを一つくれないか。」
「今日はCakePHPがお勧めとなっております。」
「じゃあ、そいつをくれ。」
「かしこまりました。」 >>703
なんで俺に絡むんだよ。
たった1個上のレスも読めないのか?
釣りなのか? >>705
何言ってるんだ?
1個上のレスを読んでるから性能って何って話だよな >>697に聞いてくれよ
俺は知らんよ。
使われた言葉返しただけなのにw 1ファイルにphp+html+css+jsべた書きが催促 出力されるHTMLがSEOに合ったものなら、途中経過は関係ない。 PHPでMVCってModel, View, Controllerの3クラスに
それぞれ適当な補助クラスをコンポジる感じでok? 検索するとViewは普通にHTML部分にしてクラスにしない奴が多いが…
それはどうだろう… >>713
別にありじゃない?
PHPTALってのもあるし
厳密には、TALに値渡す必要があるので、Viewが純粋なHTMLのみという訳ではないけど
未だにコントローラが何者なのかわからねえw
コンポーネントってのもよくわからんし。 コントローラの役割そのものがわからないというよりも『どこまでがコントローラがやるべきことなのか?』ってことかな。
ビューとコントローラで迷うことはないけど、モデルとコントローラのどっちに書くべきかな、って言うのが多い。
まぁ、経験で補うもんだろうね。 100%中の100%!!!!!!!!!!
byとぐろ兄弟 ってか3つに分けようとするから分からないんじゃない? PHP研究所って全然PHP関係の書籍ださねーな。
社内だけで技術囲ってんじゃねーぞ。 オブジェクト指向で、MVCのMとCがいまいちつかめない
処理はModel、ViewとModelを制御するController
ってある。
例えば、ある条件を満たしたときに、データファイルからデータ一覧をリスト形式にしたくて、
・データ1
・データ2
・
みたいにずらーと繰り返しして表示するとき、
modelには、ある条件を満たしたしたかどうかを判断する処理を、
viewには<div>やら<ul><li>を、
controllerには繰り返しのwhileを?
って迷ってしまう。
でもwhileて処理になるからmodelに書いた方がいいんじゃあいの?、と・・
でもmodelにwhileの処理かくと、同時に<br>やらもmodelに書いて
viewには何を?・・ってなってしまって先にすすめない・・
つづく ごめん、やっぱりつづかない。
非常にわかりにくいかもしれないけど
こういうときって、素直にcontrollerにwhile処理いれとけばいいのかな。
でも、controllerに制限させるものが二、三個ならいいけど
もっとwhile処理するものが多くなれば、
処理がかぶってくるんだけど、
それが気持ち悪くて・・
なにか上手い回避方法を教えてください で、一応考えたのが、
viewにはhtmlタグだけを、
modelには条件処理とwhile処理を、
このwhile処理の中にviewで書いたhtmlタグを
放り込んで繰り返し処理。
controllerで、このmodelに引数入れてやれば
このmodelの変数には、
条件処理された結果と、
htmlタグつきのデータ一覧が格納されて、
表示される。
みたいにしたんだけど、これでいいのかな。
wikiのまとめサイトみるとmodelにwhileかかずに
controllerに書いてたから、何か意図があってやってるのかなと Model はデータをどこからともなく持ってくる。
View にはテンプレートエンジン使って View の中でループさせる。
Controller は Model に「データ持ってこい」と頼んで、受け取ったデータを今度は View に渡して「表示しろ」と頼む。
View は渡されたデータをぶん回して表示する。
「頼む」ってのは メソッドを呼び出すことを指す。
嘘教えてたら許して >>731
というとつまり、もしも動的にデータを一覧表示させたいときなんかは、
”データ持ってこいとModelに頼む→Viewに渡して表示させる”
という一回の表示を、whileなりなんなりを使って何回も繰り返す操作を
Controllerがやるってことでいいのか。 date.txtにdate1,date2,date3,date4ていうデータが入ってたとき、
"2"という条件を与えたときに、
date1<br>
date2<br>
"4"という条件を与えたときに、
date1<br>
date2<br>
date3<br>
date4<br>
という一覧を行いたい場合。
Modelには、指定されるデータを一つ引き出せるメソッドを、
Viewには、Controllerから受け取ったModelの一つのデータの後ろに、<br>を加えてechoするメソッドを、
そしてControllerで、Modelのメソッドを実行して、得られたデータをViewのメソッドへ渡し、一つデータを表示させる、
この操作を条件分繰り返すwhileもControllerに書いておく。
で、いいのけ
超基本的な場合、イメージ的には、
・Viewは、htmlしか知らない人でも、(phpの変数以外は)htmlタグ部分がはっきりしてるので弄ろうと思えば弄れる作り
・Modelは、処理されたデータを与える
・Controllerは、初期条件をMVに与えたり、MVにあるいろいろなメソッドの中から、
必要なものを選んで、データを得たり、表示させたり(MをVに渡して表示させたり)、
MVを組み合わせて完成したものを表示させる
みたいな感じ
だけで基本的名ことがまだまだ全然わからん >>732
まあ作り方によるんだろうけど……
ループでViewを何回も呼び出すよりも、例えば配列でデータを一度に全部渡しちゃって、Viewにループしてもらったほうがスッキリしない?
Viewの中にPHPの生のコードが入るのを避けたいなら、先に挙げたテンプレートエンジン使うとかすればいいし。 >>734
たしかにそうか
ループするデータ表示のデザインて単純なものが多いだろうし
デザイン変更するときも、viewにphpのコードが入っててもそこまで苦にはならないか。
テンプレートエンジンどれがいいか決めれないし、
controllerにphpコードの種類がいっぱい入ってくると見にくいし長くなりそうだから
とりあえずはviewでループさせる方法にしてみるわ
あんがと >>727
レス全部読んでないから、的外れになるかもしれないけど、
MVCの基本コンセプトは『プログラムの着火点(エントリーポイント)は、URLである』
という考え方が中心になっているらしいよ
つまり、どんなWEBアプリもそのプログラムにアクセスしないと何も起こらないという発想。
そこから更に考えを発展させて、URLの一部にメソッドを含めよたのがMVCのポイント。
この、メソッドを含んだURLを処理する枠組みをコントローラにした訳。
だから、コントローラを中心にデータをサーバに貯めるならModelに、
データをユーザに表示するならViewにと処理系を分けた。
一般的にビジネスロジックはModelにとか言われるけど、
このビジネスロジックとはデータに正規表現をかけて別の形に置き換えるとか、
特定の数値を暗号化したりとか、殆どの処理の処理を指す。
だから、ロジックの中心はModelで処理され、コントローラはただMやVにデータを振り分けるだけに徹するのが
正しいMVC設計と言われてる。
実際のコード量もControllerが異様に肥大しているMVCは、悪いMVCとされている。
迷ったらMにロジック書いて、Cから呼出すようにする。
どうしても呼出せないロジックだけCで処理しよう。 >>736
なるほど
完全に思い込みで、
Vには、phpコードでの処理に関連するものはほとんど無くしてhtml表示メインが良い
みたいになぜか考えてしまっていて、なかなか進めなかった。
>メソッドを含んだURLを処理する枠組みをコントローラにした訳。
>だから、コントローラを中心にデータをサーバに貯めるならModelに、
>データをユーザに表示するならViewにと処理系を分けた。
これで、C、M、Vにはそれぞれこれをしようっていう考えが固まってきて
踏ん切りがついて先にすすめそうだ
とんクス ループして全部表示させるっていうのはVの仕様って気がするんだよねー。
最初の1件とか最初から100件とか、或いは全部っていうのはVの都合なわけで、
変更したいって思ったときはVだけ触ればよくしたい。
ってことで、
無駄とかなんとかは気にせずに、純粋な感じでいうと
Cの人は全部もらって、そのままVの人に渡す
っていうのがMVCぽいかな、って思う。
>>738
俺は、Vの役割は「もらったデータを表示する」だと思ってるから、
ループする処理とかはCの役割だと思うけどな。
Vは、大量データ表示用のフォーマットや、1件詳細表示用のフォーマットを
持っているという形。
Cは、指定された件数のデータを表示させる機能を持っている、という形。 抽象論も大事だけど、具体的にコードを書いていきながら進めると分かりやすくなるかもしれないね。
質問者さんは、自分の思う発想でコードを書いてさらしてみたらどうかな。
それに対していろいろな人がレビューをすると何か見えてくるかもしれない。 OOPの理論って奥が深いな。
デザインパターンなども学んで理論に忠実に沿った理想的な
プログラミングをしてみたいなとも思ったけれど、つきつめると
ケースバイケースってことに落ち着くから、こういう、忠実さを
追いかけるのは無駄な考え方のような気もしている。
この考えで合ってるよね?w それ、ASP.NETに新しく導入された「ASP.NET MVC」ってフレームワークの記事なんだよ。
そもそもASP.NETはイベントドリブンなフレームワークで、本来の意味でのMVCを採用してたんだけど、StrutsとかRoRとかがウェブで流行ったから、MSも似たようなフレームワークを作ったわけ。
だからのこれまでのASP.NETの方が本来的なMVCに近い。「ASP.NET MVC」は「ASP.NET ウェブMVC」とかって名前にすれば良かったのに。 M$って、紛らわしい名前つけるのが好きだよね。
ASP.NETにおいてMVCに関する詳しい記事かなと思ったけれど、
実際に読んでみると、まったく別なフレームワークってことだった。
違いについて理解するのがひとつ面倒になったなぁ。 PHPにおけるOOPは100mを自動車で走るようなもの
自転車を使え
走れ
歩いてもいいぞ OOPを使いまくる必要はないけど
必要な機能をモジュール化したいときにOOPをいいとこ取りすれば便利 >>748
最初に設定していた目標が概ね達成出来たからじゃね?w
っていうか、このスレに求めているものを書いていけば
盛り上がりを戻す可能性もあると思うよ。
質問するとか、何かソースを提供するとか。 FWは、その開発目的によるので、結論は出ない。
いや、あおりとかじゃなくて。 PHPのフレームワークでMVCのタイプを使ってみました。
同じ機能を作るのに、コードを書く量が少なくて済むと楽ですね!
ただ、MVCだとスクリプトのファイル数が多くなると、ゴチャゴチャして見づらいと思いました。
MVC以外のフレームワークでオススメのものはありますか?
http://www.slideshare.net/NetPenguin/mvc-2659370
・PAC
・RecursiveMVC(HMVC)
・MMVC
・Doc/View
という仕組みが紹介されていました。 >>754
ttp://d.hatena.ne.jp/sotarok/20091126/modern_php_programming_at_pfi
↑このスライド資料の72ページ目に、PHPフレームワークの評価が紹介されていました。
・CakePHP
世界でも日本でも大流行り。当然日本語での情報量も多い。
Modelが使いやすい。それ以外は嫌いだけど。
Cake3が別フレームワークにfork
・ZendFramework
世界的にシェアNo.1?
書く量の減らないドMフレームワーク
というかいわゆるライブラリ群
・symfony
これも利用者多い
大規模向け。がっちりしてる。
・Ethna
グリーはこれで動いている!(古いバージョンだけど)
・rhaco2
大本命の超変態フレームワーク
すごい
Ruby(RoR)っぽいFW → CakePHP / Lithium
Java(Struts)っぽいFW → symfony
Python(Django)っぽいFW → rhaco
というかんじでしょうか? >>756
ttp://d.hatena.ne.jp/kagigotonet/20091215/1260851032
>PHPはWeb特化言語という特性上他の言語では見られない強力な仕組みがあります。
>その特徴は他の言語では参照で取り回すところを文字列で取り回すところである、と言えるでしょう。
>可変関数
>PHPのフレームワークは、これを基本としています。ライブラリ、モジュールを動的にロードするのが非常に容易
>可変変数
>このように可変変数や可変引数を組み合わせるだけでも、少ないコード量でかなり複雑なことが可能になります。
各フレームワークのディスパッチ(処理の割当て)の仕組みを見ると、参考になりますね。 >>750
「名前空間」を活用すると、たくさんモジュールを作っても分類が楽になりますね!
ttp://d.hatena.ne.jp/Fivestar/20091215
ttp://prezi.com/0-vyhjdkslih/ >>734
>Viewにループしてもらったほうがスッキリ
そうですね。
データをループ表示させるのは、ビューの役割。
ビューの部分には
・テンプレート(HTMLファイル)
・テンプレートエンジン(HTMLファイルに文字列を当てはめるパーサー)
の二つが含まれている形にすれば、
表示に関するロジック(繰返し表示の処理など)はビューの中に置けばOK
=表示に関する機能を修正する場合、ビューの中を探せばOK >>727
MVCのモデルはどんなふうに作るか?という話で、
・トランザクションスクリプト
・ドメインモデル
という二つのスタイルがあるそうです。
ttp://pc11.2ch.net/test/read.cgi/php/1241341332/
ttp://proshile.blog.drecom.jp/archive/616
・トランザクションスクリプト
→古きよきC言語時代の関数が主体の書き方
・ドメインオブジェクト
→オブジェクト毎に内包する値と役割の責務を明確にしたOOPライクな書き方
MVCのモデルの部分は2層に分けて、
(1)ビジネスロジックコンポーネント
(2)デーアクセスロジックコンポーネント(O/Rマッパーを含む)
と分類する考え方があるそうです。
ttp://satoshi.blogs.com/life/2009/10/rails_mvc.html
ttp://d.hatena.ne.jp/p4life/20091014/1255532618
>Skinny Controller, Fat Model
・コントローラーはシンプルにする
・モデルに処理を集約する → 上記(1)ビジネスロジック=データの加工を担当
・モデルはデータの整合性を保証する → 上記(2)データアクセスロジック=データの読み書きを担当
ttp://www.virtual-tech.net/blog/2008/10/reflex-restful.html
ttp://www.virtual-tech.net/blog/uploaded_images/designold-722880.PNG
↑この図だと、モデルの部分が2層に分かれていて、
サービス層=上記(1)
ドメイン層=上記(2)
という形になるかと思います。 >>728
C側に書いてあるコードを、なるべくM側の方に移動した方がスッキリするかも?
CとMの間のデータ受け渡しについて、こんな記事がありました。
↓
ttp://q.hatena.ne.jp/1242894491
>個々のSetterをオーバーライド出来るところが
>symfonyの便利な部分じゃないでしょうか。
>これが出来ないと個々のコントローラでデータを加工するハメになります・・。
>「MVCとして洗練されている」というのは
>「MVCに忠実に機能している」というのと同義かと思います。
一口にOOPと言っても、各フレームワークでちょっとずつ使い方に違いがありますね。 >>89
フレームワークを使ってみて、OOPの使い方の理解が深まりました。
皆さん、たくさんのアドバイスをいただき、どうもありがとうございました。
分からないことがあっても、検索したり質問して1個ずつ埋めていけば、確実に進歩できると思います。
どんなプロフェッショナルな人でも、最初は素人だった…
これからPHPの勉強を始める方がいましたら、焦らずに頑張ってくださいね!(*^o^*)/ オブジェクト指向ってrequire文とinclude文みたいな考えと同じかな?
必要なときにどこからでも呼び出せるプログラムみたいなものだよね。 OOPの説明で一番わかりやすかったのがプレーヤーの例
プレーヤーを継承した CDプレーヤー,MP3プレーヤー がある
それぞれに 再生,停止,早送り,巻き戻し,次トラック,前トラック という機能(メソッド)がある
具体的な処理はそれぞれが行うので,使う人はプレーヤーの処理している内容を
理解している必要はなく,再生したいときに再生ボタンを押すという事だけ
分かっていればいい。(カプセル化)
つまり考え方であって,そういう意味では間違ってないのかもしれない。 それぞれにあるのではなく、プレイヤーという抽象クラスにあるのでは? >>773
ダックタイピングなら、それぞれにあってもいいよね
>>773
そうなんだけど,具体的な実装がそれぞれ違うという意味で
ああいう書き方にした。
>>775
PHPは型にしばられない(しばられなさすぎて困る)スクリプト言語だからね。
逆に、静的言語のように型を意識しすぎると、スクリプト言語のメリットが少なくなると思う。
「じゃぁ、お前、クラス階層つかわねーのか?」と言われればノー
コンポーネント(レイヤ)の中では、型を意識し、拡張する場合は継承も使用する。
コンポーネント間の接続は型ではなくメッセージ(メソッド)に束縛させるように意識している。
でも最近は、interface作って、抽象クラス作ってというのがおっくうになってきたので、可能ならメソッドポインタによるコールバックで済ませちゃうこともしばしば。
javaや.NETはたまたPythonあたりの純血PGが書けばOOPっぽいソースになると思うよ。
PerlとかPHPから始めました、ってのはだめだな。 PHP6のオブジェクト指向ってなにか大きな変化ある? 機能追加がほとんどか。
じゃあ、PHP5のコードをPHP6に移植しても問題なく動くってことでいい?
PHP4→PHP5のときは大変みたいだったけど。
同じ思いをしたくない。 逆に互換性なんかいいから関数の無茶苦茶な命名規則とか直して欲しい 関数はもうほうっておいて、
公式にオブジェクト指向ライブラリを提供すればよい 質問するのが怖いんだけど、自分はフォームのパーツを呼び出すのに
オブジェクト指向(クラス)を使ってるつもりなんだけど正しいのか自信がない
クラスformPartsの中で各プルダウンやラジオボタンの要素(nameとvalue)を
外部ファイルから読み込んどいて
$fp = new formParts();
$pref = $fp->callPullDown('prefecture',$val);
$job = $fp->callPullDown('job',$val);
$sex = $fp->callRadioButton('sex',$val);
こんな感じでメソッドでパーツの種類を指定しつつ(ラジオボタンかプルダウンか)
そのパーツの要素(都道府県とか職業とか)と既定値($val)を投げて呼び出してる。
プルダウン要素とかは各メソッド内部で引数によって外部ファイルから読みこんでる。
クラスってこんな使い方でいいの? 継承とかはさっぱりわからない、どういう状況で使うんだか。
あと1さん凄いね、ガッツがあるなぁ。。 oopってさ
PHP最大の武器であるHTMLとの親和性の高さを殺してるよね いまの流行はテンプレートだから
PHPのHTML埋め込みなんてもう古い テンプレートってどんな利点があるの?
そもそもPHP自体テンプレートみたな言語じゃん。
index.php
<?php
$title = "hoge";
$hello = "hello world";
include "template.php";
?>
template.php
<html>
<head><title><?php echo $title ?></title><head>
<body>
<h1><?php echo $hello ?></h1>
</body>
</html>
こういうのとは違うの? ほとんどの言語は、HTMLの中で
コードを動かすという発想で作られていない。
コードーの中でHTMLを出力するという発想。
そういう言語ではテンプレートが重要。
PHPでテンプレートの意味が薄いのは確か
ただテンプレートの意味がまったくないかというと、そうではなく
分業作業。つまりプログラマとデザイナに分かれて開発するときは便利。
デザイナはphpコードはまったく知らない。だからなるべくシンプルな
記号レベルの書き方であってほしい。しかもDreamweaverのような
HTMLエディタで見たときに不具合無く表示されるものの方がいい。 デザイナーでもHTMLとPHPの繋がりぐらいは分かる
いや、分かるようにPHPを書かなければならいと思う
それがPHP ここで議論してる奴らは世に影響力のないカスばかりだから参考にしなくて良い 852 忍者Perl ◆M5ZWRnXOj6 [] 2010/08/20(金) 13:30:09 ID: Be:
マルチしてんじゃないですよクソゴミww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)wwww(笑)ww
ww(笑)wwww(笑)ww
PHPやってるやつノウタリンばっかりwwwwwwww いいんです!
コーディングが楽だから、OOPで良いんです!! 逆だろ
OOPだからボトルネックが把握しやすくてメンテナンスや新実装がしやすくなる 遅くなるって体感でわかるほど遅くなるのか?
だったら書き方おかしいよ >>736
コントローラを肥大させてはならないという概念ではわかりにくい。
もっと具体的に境界線を引くべきだと思う。以下俺の意見なんだけど、
MVCってユニットテストために
ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。
具体的に言うとこんな感じ。
View(GUI, xml, html, json)
Controller(Session, Request, Form, 画面遷移などWeb独自のデータ)
Model(RDB, KVS)
MとCが分離されることでMはWebスコープから分離され、CはSQLから分離される。
でもこの理屈だとVとCの関係がおかしくなっちゃうね。
CがVにデータを渡すときはリクエストスコープを経由しないで
直に関数の引数で整数や文字列、オブジェクトを渡すべきって話になるから。 >>813
> MVCってユニットテストために
> ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。
正しいが、これは現場的な視点の1つの考え方。
MVCは、スケーラブルなサイト構築のためのパラダイムという方が、しっくりくると思うが... PHPのOOPフレームワークを教えて下さい。
イメージとしてはJavaのStrutsのようなものです。 JavaStrutsはさておき、おすすめはYIIだな。PHPの中では美しい。 >>818
YII以外では無いのでしょうか?
YIIはOOPフレームワークとしては不完全です。 >>820
オブジェクト指向言語であればオブジェクトを使用するところで、
配列を使用する点。 >>821
なんでOOPフレームワークを使いたいの? >>822
OOPに慣れてるからです。
オブジェクトとして定義するところで
phpの場合、配列になるのでいらいらします。
たとえばCakePHP。ModelがModelになっていない。
やはり後付けでOOP機能が加わった言語では無理があるのですね。 >>823
ModelがModelになってないというのは具体的にどういうこと? >>824
どのオブジェクト指向言語を経験しましたか?
それにあわせて話をします。 >>823
phpで本格的なオブジェクト指向ははじめから無理だよ。 >>828
ぜひStrutsの話を聞きたいですね。
たとえばCakePHPやsymphonyとどう違いますか? PHPのOOP関連機能が中途半端なのは当たり前。
実行速度が遅いPHPではそもそも向いていない。 >>829
話をすると言って聞くばかりなのはなんでだ? >>831
Javaのフレームワークのことを教えてください >>832
ModelがModelになってないというのは具体的にどういうこと? >>833
Javaのフレームワークの比較で語りましから、あなたが今までにどのJavaフレームワークを使ってきたのか教えてください >>835
無知の自慢するべきではない。
あなたは一生、PHPでOOPの真似やってた方がよい。 完全にoopオリエンテッドな言語でしかoopしないって主張が、かなりダメぽ phpは継ぎ接ぎだからoopに向いてない
速度の面でも不利 >>834
答えられないなら最初から言うな見栄っ張りw
>>843
JavaのOOPについて語ってください。
話はそれからです。 質問者がJavaのどのフレームワークを使ったことがあるか書くべき
回答者がそのフレームワークとCakePHPを比較すべき そんな比較はどうでもいい。
phpのOOP機能は単なるおもちゃ。 ttp://kameleon.s241.xrea.com/wiki/index.php?%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B
すいません
ここのフレームワークのソースをダウンロードしたいんですが、ダウンロードできません。
どこかで入手できないでしょうか ログインできませんでした。
10分ほどしてから再度お試しください。 PHPでOOPやるとかアフォだろ
PHP自体カス以下だし PHPはC++と同じで、クラスに属さない
関数があるんだよ。 クラスに属さない関数が多すぎ
そして、関数名が長くて、使いたいときに思い出しにくく覚えにくい。命名法が統一されてない。 PHPでOOPやるとかwwww
笑わせるなよwwww 黙れ、情弱!
便所に行ったら手ぐらい洗え
つttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan01.jpg
ttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan02.jpg
ttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan05.jpg 俺はゴミカスだがエリートゴミカスだ
お前らのような下級ゴミカスとは格が違う >>857
逆に女子はトイレ行ったら手を洗うの禁止な。 Java WicketとかPHP Piece Frameworkに流行ってほしいな。
平たく言えば何でもセッションに突っ込んでるだけなんだけどね。 実際トレイトって、あれば便利な気はするけどどこで使うのか思いつかん。
だれか使いこなせてるって人いますか? なんでもセッションでいいよな
PHPってそういうもんだろ セッションハイジャックの脆弱性を可能な限り排除できるなら、
セッション利用でOK。
PHPもOOPも時代遅れ
今はLOOP、すなわち論理オブジェクト指向プログラミングの時代 PHPerがJavaのIDEなんか使ってんじゃないよ。
秀丸でちょちょいとやるのがオツってもんだ >>866
>実際トレイトって、あれば便利な気はするけどどこで使うのか思いつかん。
>だれか使いこなせてるって人いますか?
traitは scala から持ってきた仕組み。
(もちろん scala も他の言語から影響を受けている)
trait とは:
- Mixin - Wikipedia http://ja.wikipedia.org/wiki/Mixin
- traitは実装を含めることができるinterface
- コードのコピペをfunctionalityにしただけ
利用シーンとしては、継承したくないけど、
ある実装を、このクラスだけでは使用したいという場合に
traitを作って、それを使います。(だから、コードのコピペと表現した↑)
AS3を書いてたときはmixinはイベント機能を追加する目的で
よく使ってた
以下PHPでの実例をどうぞ↓
https://www.google.co.jp/#q=php+oop
約 10,600,000 件 (0.13 秒)
PHPのオブジェクト指向入門 | オブジェクト指向PHP.NET
http://www.objective-php.net/&amp;#8206; Formのクラス作ったら500行になっちゃった
これって糞プログラムの部類なのかな・・・
シンプルに書きたいのに機能付け加えていくとどうしても肥大化してしまう 美少女オブジェクトに排便しろというメッセージを飛ばすのか
胸が熱くなるな ガベージコレクションは自動で実行されるものなので我々が命令するものではない 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
TVD73U3V71