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^)／ 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に関する詳しい記事かなと思ったけれど、
実際に読んでみると、まったく別なフレームワークってことだった。
違いについて理解するのがひとつ面倒になったなぁ。 PHPにおけるOOPは100ｍを自動車で走るようなもの
自転車を使え
走れ
歩いてもいいぞ ＯＯＰを使いまくる必要はないけど
必要な機能をモジュール化したいときにＯＯＰをいいとこ取りすれば便利 >>748
最初に設定していた目標が概ね達成出来たからじゃね？ｗ
っていうか、このスレに求めているものを書いていけば
盛り上がりを戻す可能性もあると思うよ。
質問するとか、何かソースを提供するとか。 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？
書く量の減らないドＭフレームワーク
というかいわゆるライブラリ群
・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のモデルの部分は２層に分けて、
(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
↑この図だと、モデルの部分が２層に分かれていて、
サービス層＝上記(1)
ドメイン層＝上記(2)
という形になるかと思います。 >>728
C側に書いてあるコードを、なるべくM側の方に移動した方がスッキリするかも？
CとMの間のデータ受け渡しについて、こんな記事がありました。
↓
ttp://q.hatena.ne.jp/1242894491
>個々のSetterをオーバーライド出来るところが
>symfonyの便利な部分じゃないでしょうか。
>これが出来ないと個々のコントローラでデータを加工するハメになります・・。
>「MVCとして洗練されている」というのは
>「MVCに忠実に機能している」というのと同義かと思います。
一口にOOPと言っても、各フレームワークでちょっとずつ使い方に違いがありますね。 >>89
フレームワークを使ってみて、OOPの使い方の理解が深まりました。
皆さん、たくさんのアドバイスをいただき、どうもありがとうございました。
分からないことがあっても、検索したり質問して１個ずつ埋めていけば、確実に進歩できると思います。
どんなプロフェッショナルな人でも、最初は素人だった…
これから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自体テンプレートみたな言語じゃん。
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ってユニットテストために
> ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。
正しいが、これは現場的な視点の１つの考え方。
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に向いてない
速度の面でも不利 
