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

お？サンプルか？

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

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

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

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

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

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

凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
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を参照するから。

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

ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって
性能うんぬんは考えてないんだよな

勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい

つーか開発効率は性能に含まれるだろう

は？

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に聞いてくれよ
俺は知らんよ。
使われた言葉返しただけなのにｗ

1ファイルにphp+html+css+jsべた書きが催促

ＳＥＯ的に最悪だな

出力されるHTMLがSEOに合ったものなら、途中経過は関係ない。

PHPでMVCってModel, View, Controllerの3クラスに
それぞれ適当な補助クラスをコンポジる感じでok?

ng

検索するとViewは普通にHTML部分にしてクラスにしない奴が多いが…
それはどうだろう…

>>713
別にありじゃない？
PHPTALってのもあるし
厳密には、TALに値渡す必要があるので、Viewが純粋なHTMLのみという訳ではないけど

未だにコントローラが何者なのかわからねえｗ
コンポーネントってのもよくわからんし。

基礎中の基礎すぎるだろ

コントローラの役割そのものがわからないというよりも『どこまでがコントローラがやるべきことなのか？』ってことかな。

ビューとコントローラで迷うことはないけど、モデルとコントローラのどっちに書くべきかな、って言うのが多い。


まぁ、経験で補うもんだろうね。

100%中の100%！！！！！！！！！！

ｂｙとぐろ兄弟

ってか3つに分けようとするから分からないんじゃない？

>>719
なんだ君も教えて君か

アセクサ

アホクサ

保守しときます。

保守要らない板だから・・

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に書いてたから、何か意図があってやってるのかなと

MVCまだ早いんでないかな

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は、大量データ表示用のフォーマットや、１件詳細表示用のフォーマットを
持っているという形。
Cは、指定された件数のデータを表示させる機能を持っている、という形。

抽象論も大事だけど、具体的にコードを書いていきながら進めると分かりやすくなるかもしれないね。
質問者さんは、自分の思う発想でコードを書いてさらしてみたらどうかな。
それに対していろいろな人がレビューをすると何か見えてくるかもしれない。

PHPじゃないけど、こんな記事があった。

ASP.NET MVC入門
http://www.atmarkit.co.jp/fdotnet/aspnetmvc/aspnetmvc01/aspnetmvc01_01.html

OOPの理論って奥が深いな。
デザインパターンなども学んで理論に忠実に沿った理想的な
プログラミングをしてみたいなとも思ったけれど、つきつめると
ケースバイケースってことに落ち着くから、こういう、忠実さを
追いかけるのは無駄な考え方のような気もしている。
この考えで合ってるよね？ｗ

結論出ちゃったじゃないか

それ、ASP.NETに新しく導入された「ASP.NET MVC」ってフレームワークの記事なんだよ。
そもそもASP.NETはイベントドリブンなフレームワークで、本来の意味でのMVCを採用してたんだけど、StrutsとかRoRとかがウェブで流行ったから、MSも似たようなフレームワークを作ったわけ。
だからのこれまでのASP.NETの方が本来的なMVCに近い。「ASP.NET MVC」は「ASP.NET ウェブMVC」とかって名前にすれば良かったのに。

M$って、紛らわしい名前つけるのが好きだよね。
ASP.NETにおいてMVCに関する詳しい記事かなと思ったけれど、
実際に読んでみると、まったく別なフレームワークってことだった。
違いについて理解するのがひとつ面倒になったなぁ。

stackoverflowを作ったヤツね。

保守しとくね。

なんでカソってんだー

PHPにおけるOOPは100ｍを自動車で走るようなもの
自転車を使え
走れ
歩いてもいいぞ

ＯＯＰを使いまくる必要はないけど
必要な機能をモジュール化したいときにＯＯＰをいいとこ取りすれば便利

>>748
秋田ｗ

>>748
最初に設定していた目標が概ね達成出来たからじゃね？ｗ
っていうか、このスレに求めているものを書いていけば
盛り上がりを戻す可能性もあると思うよ。
質問するとか、何かソースを提供するとか。