PHPでOOP
>>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