PHPでOOP
■ このスレッドは過去ログ倉庫に格納されています
00011 ◆SWtzLesEmM
2007/02/23(金) 13:35:52ID:???プロシージャ指向（手続き型、構造化プログラミング）でもできますが、
オブジェクト指向を使った場合の恩恵を享受するために、
PHPでオブジェクト指向プログラミングの勉強をしてみましょう。
＜目的＞
PHP5でオブジェクト指向プログラミングを行なうための知識を習得する。
（PHP4のOOPもOK、このスレが1000に行く前にPHP6が出たらPHP6のOOPもOK）
＜方向性＞
・このスレは、プログラミング初心者、PHP初心者の勉強の場として利用することを前提にします。
・PHPのOOPの話題に限定します。
（Ruby、Python、Javaなど他言語のOOPについては、その言語のスレッドでお願いします。）
・PHPのOOP学習に役立つ本、WEBサイトの紹介をお願いします。
＜その他＞
・略記は、「OO」＝「オブジェクト指向」、「OOP」＝「オブジェクト指向プログラミング」でお願いします。
・質問をする人はなるべくトリップを付けましょう。
・荒らし、煽り、叩き、気違いは無視・無干渉でお願いします。
このスレで、今日から貴方もOOP！！！＼(^o^)／
0636nobodyさん
2008/12/20(土) 18:07:36ID:???大雑把に言うと、処理を始める前に可能なパラメータの検証全般。
純粋に入力値だけを見て判定できるものだな。システムや環境の状態を見なくとも判定できるエラーを出す役割。
処理を始めないと分からないもの（DBに指定されたエントリーがあるかとか）は、バリデーションでは扱わない。
DBにこの値があった場合はクッキーにこれが無いといけない…みたいなのも対象外。
日付として「'9999-12-31'」が指定されてもバリデーションでは引っ掛けない。これは有効な入力。
「'2008-13-45'」はバリデーションでエラーとして引っ掛ける。この日付が有効になる事はあり得ないから。
メールアドレスが正しいフォーマットかをチェックするのはバリデーションで、それが有効なメールアドレスかをチェックするのはモデル。
ユーザーIDとして正しいフォーマットならばバリデーションは通るが、当該ユーザーがいない場合モデルがエラーを出す。
0637nobodyさん
2008/12/21(日) 00:53:43ID:???なんとなく分かるけど、
例えばそれだと「2008-13-45は日付(のつもり)」ってことを
コントローラが知っとかないといけないってことだよね？
あと、日付が必要なくなった、とかいうときは
コントローラーを変更しないといけないってことにならない？
なんか拘ってるようでアレだけどお勉強スレってことで許してｗ
0638nobodyさん
2008/12/21(日) 00:57:41ID:???hoge.php?date=20081231
とか。
0639nobodyさん
2008/12/21(日) 12:32:43ID:???「コントローラ」の指している範囲が俺と違う気がする。
俺はディスパッチャ（処理の振り分け）部分じゃなくて、そこから振り分けられる先のコントローラを指している。
ぐぐったが、「アクション」としてクラスにして丸ごとコントローラから切り離す文化圏もあるようだな。
「日付のつもりで送られてくる文字列がある」という事実は、ディスパッチャは（たいていの場合）知らない。
が、コントローラ（アクション）は知っている。だって知らないと日付具象モデルに処理を引き渡しようがないからな。
Cにはどの道変更が入る。リクエストをモデルに引き渡すのが仕事だからな。
「日付がどこからどう渡ってくるか」はCの管轄であってMじゃない。Mはそれを知っていてはいけない。
Mは「日付を渡されたらどうする」だけ知っていればよく、実際問題どこに日付があるかはCが隠蔽すべき。
たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
「省略時は日付を無視して過去のレコードを全取得する」という場合は、データ取得ロジックが変更なのでまずMは変わる。
制御の構造、呼び出しインターフェイスも変わるのでCも変わる。
0640nobodyさん
2008/12/21(日) 12:37:44ID:???>638
入力値以外のもの（DB内の値とか処理結果）の検証は当然モデル。
というか、そういうのは一般にはバリデーションとは言わずアサーションと呼ぶ。
0641nobodyさん
2008/12/21(日) 13:45:12ID:???Cは振り分けだけが仕事だと思ってたんだけど。
その先にさらに C があることなんてあるのか。
サブコントローラーみたいな感じ？
0642nobodyさん
2008/12/21(日) 14:51:26ID:???やっぱ、そこか。
例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。
で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。
で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。
これをMVCのうち、MとCのどっちに置くかの問題。
MVC、MVCって言ってるけど、本質的には4層なんだよ。
処理の振り分けに1層を割くならば、4層なくてはならない。
処理の振り分け=呼び出すCの決定（ディスパッチャ）→どのMを呼び出すかを制御する（コントロール）
→データを実際に扱う（モデル）→表示（ビュー）、となる。
実際のフレームワークだと、RailsやZendはDispatcherが振り分けを担当し、制御はコントローラが執っている。
（だから、おまいの目から見れば、コントローラは仕事をやりすぎに見えるはず）
SymfonyやCakeだとControllerがディスパッチを担当し、制御はActionが執っている。
CodeIgniterだとディスパッチは単一のエントリポイント（リクエストを受けるphpファイル）であるindex.phpが行なって、制御はCが行なっている。
0643nobodyさん
2008/12/21(日) 15:35:51ID:???>たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
>この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
これって制御じゃなくてロジックだからモデル的仕事じゃねぇの？
0645nobodyさん
2008/12/21(日) 16:03:24ID:???0647nobodyさん
2008/12/24(水) 12:54:19ID:???実装するときは、コントロールで括るよな？
0648642
2008/12/24(水) 22:47:37ID:???M・V・Cで分けるならCってのは同意。いちおう
> 処理の振り分けに1層を割くならば
と予防線は張ってあるわけだが。
俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。
0649nobodyさん
2008/12/25(木) 12:55:55ID:???> Controllerの親クラスとかControllerFactoryでディスパッチする事が多い
ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの？
0650nobodyさん
2009/01/04(日) 21:25:44ID:???0651nobodyさん
2009/01/10(土) 18:38:23ID:???0652nobodyさん
2009/01/18(日) 01:35:36ID:???0653nobodyさん
2009/01/26(月) 20:14:56ID:???0654nobodyさん
2009/02/02(月) 14:37:18ID:JcAer1H1自作のモチベ下がっちまったい。
0655nobodyさん
2009/02/02(月) 14:46:20ID:???0656nobodyさん
2009/02/02(月) 14:54:00ID:???0657nobodyさん
2009/02/02(月) 15:06:11ID:???で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。
0658nobodyさん
2009/02/02(月) 20:06:44ID:???で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ
0659nobodyさん
2009/02/03(火) 00:06:52ID:???要するにフレームワークの魅力に気付いたわけですよ。
0660nobodyさん
2009/02/03(火) 01:52:40ID:???0661nobodyさん
2009/02/04(水) 08:03:26ID:???プログラムは体感して分かっていくものなのだから。
0662nobodyさん
2009/02/04(水) 21:38:41ID:???自作云々は別にして。
0663nobodyさん
2009/02/05(木) 22:29:31ID:6GWaaOT60664nobodyさん
2009/02/06(金) 07:54:15ID:???PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。
0666nobodyさん
2009/02/09(月) 20:26:45ID:???0667nobodyさん
2009/02/12(木) 07:33:22ID:???0668nobodyさん
2009/02/12(木) 09:08:20ID:???0670nobodyさん
2009/02/12(木) 20:11:52ID:???0671nobodyさん
2009/02/12(木) 20:25:45ID:???0673nobodyさん
2009/02/12(木) 20:59:58ID:???0674nobodyさん
2009/02/12(木) 21:37:52ID:???0675nobodyさん
2009/02/12(木) 22:00:11ID:???0676nobodyさん
2009/02/13(金) 20:54:05ID:???0677nobodyさん
2009/02/15(日) 23:40:26ID:???メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。
0678nobodyさん
2009/02/16(月) 00:05:47ID:???0679nobodyさん
2009/02/16(月) 00:44:15ID:???0680nobodyさん
2009/02/16(月) 11:09:32ID:IOY0ae9eでも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。
0681nobodyさん
2009/02/16(月) 19:31:23ID:???いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。
なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。
0682nobodyさん
2009/02/16(月) 23:33:26ID:???ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。
0683nobodyさん
2009/02/17(火) 12:38:03ID:???0684nobodyさん
2009/02/17(火) 20:53:57ID:???それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。
0685nobodyさん
2009/02/23(月) 20:40:12ID:???いうのではなく、その理由の部分を述べていくといいかもね。
0686nobodyさん
2009/02/23(月) 21:35:23ID:???0687nobodyさん
2009/02/23(月) 22:27:49ID:???個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。
0688nobodyさん
2009/02/23(月) 23:55:46ID:???0689nobodyさん
2009/02/24(火) 02:09:17ID:???いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。
また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。
0690nobodyさん
2009/02/24(火) 12:23:13ID:???0691nobodyさん
2009/02/24(火) 12:40:12ID:???0693nobodyさん
2009/02/24(火) 20:31:42ID:???俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。
0695nobodyさん
2009/02/25(水) 06:21:18ID:???聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。
0696nobodyさん
2009/02/26(木) 22:25:57ID:???クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかｗ
0697nobodyさん
2009/02/26(木) 23:57:14ID:???性能うんぬんは考えてないんだよな
0698nobodyさん
2009/02/27(金) 00:54:42ID:???0699nobodyさん
2009/02/27(金) 05:45:51ID:???0700nobodyさん
2009/02/27(金) 06:00:50ID:???0701nobodyさん
2009/02/27(金) 13:31:01ID:???つーか開発効率は性能に含まれるだろう
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:???
つーか開発効率は性能に含まれるだろう
0704nobodyさん
2009/02/27(金) 20:00:15ID:???「今日はCakePHPがお勧めとなっております。」
「じゃあ、そいつをくれ。」
「かしこまりました。」
0708nobodyさん
2009/02/28(土) 04:26:33ID:???0709nobodyさん
2009/02/28(土) 08:03:49ID:???0710nobodyさん
2009/02/28(土) 08:44:26ID:???0711nobodyさん
2009/03/04(水) 21:56:11ID:vdYaMRthそれぞれ適当な補助クラスをコンポジる感じでok?
0712nobodyさん
2009/03/04(水) 22:30:14ID:???0713nobodyさん
2009/03/04(水) 22:51:16ID:???それはどうだろう…
0714nobodyさん
2009/03/04(水) 23:44:42ID:???別にありじゃない？
PHPTALってのもあるし
厳密には、TALに値渡す必要があるので、Viewが純粋なHTMLのみという訳ではないけど
0715nobodyさん
2009/03/05(木) 10:13:09ID:???コンポーネントってのもよくわからんし。
0716nobodyさん
2009/03/05(木) 11:05:22ID:???0717nobodyさん
2009/03/05(木) 12:25:35ID:???ビューとコントローラで迷うことはないけど、モデルとコントローラのどっちに書くべきかな、って言うのが多い。
まぁ、経験で補うもんだろうね。
0718nobodyさん
2009/03/05(木) 17:40:27ID:???ｂｙとぐろ兄弟
0719nobodyさん
2009/03/06(金) 04:31:52ID:???0721nobodyさん
2009/03/10(火) 12:40:11ID:???0722nobodyさん
2009/03/29(日) 09:52:31ID:???0723nobodyさん
2009/04/06(月) 08:51:50ID:???0724nobodyさん
2009/04/06(月) 09:51:43ID:???0725nobodyさん
2009/04/08(水) 23:43:02ID:???社内だけで技術囲ってんじゃねーぞ。
0726nobodyさん
2009/04/08(水) 23:49:40ID:???0727nobodyさん
2009/04/10(金) 03:54:17ID:4A05Vd6N処理はModel、ViewとModelを制御するController
ってある。
例えば、ある条件を満たしたときに、データファイルからデータ一覧をリスト形式にしたくて、
・データ1
・データ2
・
みたいにずらーと繰り返しして表示するとき、
modelには、ある条件を満たしたしたかどうかを判断する処理を、
viewには<div>やら<ul><li>を、
controllerには繰り返しのwhileを？
って迷ってしまう。
でもwhileて処理になるからmodelに書いた方がいいんじゃあいの？、と・・
でもmodelにwhileの処理かくと、同時に<br>やらもmodelに書いて
viewには何を？・・ってなってしまって先にすすめない・・
つづく
0728727
2009/04/10(金) 03:59:45ID:4A05Vd6N非常にわかりにくいかもしれないけど
こういうときって、素直にcontrollerにwhile処理いれとけばいいのかな。
でも、controllerに制限させるものが二、三個ならいいけど
もっとwhile処理するものが多くなれば、
処理がかぶってくるんだけど、
それが気持ち悪くて・・
なにか上手い回避方法を教えてください
0729nobodyさん
2009/04/10(金) 04:08:52ID:4A05Vd6Nviewにはhtmlタグだけを、
modelには条件処理とwhile処理を、
このwhile処理の中にviewで書いたhtmlタグを
放り込んで繰り返し処理。
controllerで、このmodelに引数入れてやれば
このmodelの変数には、
条件処理された結果と、
htmlタグつきのデータ一覧が格納されて、
表示される。
みたいにしたんだけど、これでいいのかな。
wikiのまとめサイトみるとmodelにwhileかかずに
controllerに書いてたから、何か意図があってやってるのかなと
0730nobodyさん
2009/04/10(金) 04:22:59ID:???0731nobodyさん
2009/04/10(金) 09:37:55ID:???View にはテンプレートエンジン使って View の中でループさせる。
Controller は Model に「データ持ってこい」と頼んで、受け取ったデータを今度は View に渡して「表示しろ」と頼む。
View は渡されたデータをぶん回して表示する。
「頼む」ってのは メソッドを呼び出すことを指す。
嘘教えてたら許して
0732nobodyさん
2009/04/10(金) 10:04:35ID:???というとつまり、もしも動的にデータを一覧表示させたいときなんかは、
”データ持ってこいとModelに頼む→Viewに渡して表示させる”
という一回の表示を、whileなりなんなりを使って何回も繰り返す操作を
Controllerがやるってことでいいのか。
0733nobodyさん
2009/04/10(金) 10:51:33ID:???"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を組み合わせて完成したものを表示させる
みたいな感じ
だけで基本的名ことがまだまだ全然わからん
0734nobodyさん
2009/04/10(金) 12:01:58ID:???まあ作り方によるんだろうけど……
ループでViewを何回も呼び出すよりも、例えば配列でデータを一度に全部渡しちゃって、Viewにループしてもらったほうがスッキリしない？
Viewの中にPHPの生のコードが入るのを避けたいなら、先に挙げたテンプレートエンジン使うとかすればいいし。
0735nobodyさん
2009/04/10(金) 12:17:29ID:???たしかにそうか
ループするデータ表示のデザインて単純なものが多いだろうし
デザイン変更するときも、viewにphpのコードが入っててもそこまで苦にはならないか。
テンプレートエンジンどれがいいか決めれないし、
controllerにphpコードの種類がいっぱい入ってくると見にくいし長くなりそうだから
とりあえずはviewでループさせる方法にしてみるわ
あんがと
0736nobodyさん
2009/04/10(金) 12:48:47ID:???レス全部読んでないから、的外れになるかもしれないけど、
MVCの基本コンセプトは『プログラムの着火点（エントリーポイント）は、URLである』
という考え方が中心になっているらしいよ
つまり、どんなWEBアプリもそのプログラムにアクセスしないと何も起こらないという発想。
そこから更に考えを発展させて、URLの一部にメソッドを含めよたのがMVCのポイント。
この、メソッドを含んだURLを処理する枠組みをコントローラにした訳。
だから、コントローラを中心にデータをサーバに貯めるならModelに、
データをユーザに表示するならViewにと処理系を分けた。
一般的にビジネスロジックはModelにとか言われるけど、
このビジネスロジックとはデータに正規表現をかけて別の形に置き換えるとか、
特定の数値を暗号化したりとか、殆どの処理の処理を指す。
だから、ロジックの中心はModelで処理され、コントローラはただMやVにデータを振り分けるだけに徹するのが
正しいMVC設計と言われてる。
実際のコード量もControllerが異様に肥大しているMVCは、悪いMVCとされている。
迷ったらMにロジック書いて、Cから呼出すようにする。
どうしても呼出せないロジックだけCで処理しよう。
■ このスレッドは過去ログ倉庫に格納されています