PHPでOOP

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^)／

簡易な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って両立できるの？

MVCをOOPで実現するんだろｗ

これどうなの？

ttp://www13.plala.or.jp/naka_jima/php/chapter12.html

どうって何が？

MVCだと必ずフレームワークを使わなければならないわけでもないよね。ちがうの？
それとも、非常に単純なクラス構成でMVCを実現しようという考えが間違いとか？

別にいいんじゃ？

>>606見たんだけど、MVCってこんななの？
View や Model 1つに対して1ファイルみたいだけど、ファイル量半端ないことになりそう。

DBの形式や最終的な見せ方によって、ファイル数は変わるんじゃないの？

でも、MVCってわりとファイル多めだよな！

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);

なんじゃそりゃ

最後の一行間違い

せめてクラスは３つ以上にするべきだろ。
最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで
出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく
なると思うんだけど。

これはMVCどこがやるのが妥当か？
ってところで迷う。
時々、曖昧なのが出てきちゃう。

>>619
ここで事例を通じて具体的な意見を交わしていけばどうかな？」

例えば・・・
掲示板
■コントローラ：処理の内容を判断するクラス
・プログラムが実行された時、一番最初に実行される
・POSTの値をみて、以下の処理にてどれに該当するかを判断する
　・データを表示する
　・データを書込む
　・編集用のフォームを表示する

■ビュー：htmlのレイアウト表示を担当するクラス
・以下のメソッドを持つ
　・データをhtmlで表示する
　・データ編集用htmlを表記する

■モデル：データファイルを管理するクラス
・ファイルの読み込み、書込みをする
・外部とは１件分のデータはBBSLineクラスでやりとりする

>>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を使うときは必ずメソッドＡ呼び出してメソッドＢ、メソッドＣを実行しなければならない。
さらに、そういう３連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが
悪くなると思うから。

試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。

>>626
うｐきぼん

>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は日付(のつもり)」ってことを
コントローラが知っとかないといけないってことだよね？

あと、日付が必要なくなった、とかいうときは
コントローラーを変更しないといけないってことにならない？


なんか拘ってるようでアレだけどお勉強スレってことで許してｗ

って、もしかして、リクエストとして渡ってくるものを想定してるのかな。

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
横槍で質問してすまんかった。
すげーわかりやすい。
勉強になった。ありがとう。

4層ｗｗｗ

>>645
あなたの顔に死相が出ていますよ。4層だけに。

考え方としてディスパッチとコントロールは分けるべきだが、
実装するときは、コントロールで括るよな？

>647
M・V・Cで分けるならCってのは同意。いちおう
> 処理の振り分けに1層を割くならば
と予防線は張ってあるわけだが。
俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。

>>648

> Controllerの親クラスとかControllerFactoryでディスパッチする事が多い

ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの？

保守

保守

手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。

お？サンプルか？

勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。

自作のモチベ下がっちまったい。

自作する理由は楽するためじゃないだろう

もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい

元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。

で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。

凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ

まぁ、たぶんそんな感じ。
要するにフレームワークの魅力に気付いたわけですよ。

先に気づいてからやれば良かったな

そういうのは簡単に気づけないだろう。
プログラムは体感して分かっていくものなのだから。

俺としては魅力に気付けただけでも大きな進歩だ。

自作云々は別にして。

あけおめ

では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ？
PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。

>>4
宣伝乙

えらく昔の書き込みにレスしてるな。

フレームワークの魅力についてまとめてみるか？

どうぞ

>>667
wikiにしてもらえるなら俺も手伝う

いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る

なぜにフレームワークの魅力をまとめようと？

>>662 ≠ >>667
だからね。
俺は人に語れるほどまだ理解してないから。

なんだ教えて君か

おまえもな

サポートするといってるんだから、教えてじゃないだろｗ

ttp://q.hatena.ne.jp/1188498291

>>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの
メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。

一問一答形式でwikiでも作るか

visualstudioが優秀すぐる

Java とか C#やったほうが飲み込みは早くなるのかな。
でも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。

>>680
いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。

なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。

ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。
ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。

でも、perlってすぐ忘れちゃうよな...

>>683
それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。

PHP では OOP を学べないという意見があるが、結論だけ
いうのではなく、その理由の部分を述べていくといいかもね。

別に学べるのでは？

ん、どこかにPHPでは学べないと書いてあるのかな？

個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。

オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。

出る幕はあると思うが、最終的にフレームワークを構築することになると思う。

いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。

また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。

WEBアプリでもActionScript3なら、バリバリOOPだYO!

まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。

>>691
エンタープライズならそんなケースいくらでもあるだろｗ

>>689
俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。

>>693
ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが

>>692
聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。

クライアントマシンの性能がこれだけアップしているのに、
クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかｗ