PHPでOOP

>>545
君の語りを見てオナニレスてことに確信がもてたよ
これらのレスは君の自己満足以外に何も生まれないよ結果としてね

>>547
ああ、そうか。だったら君はもう来るな。

１が名無しとなって言い訳してるくさいな

>>550
俺は１じゃないんだけどな。言い返せなくてそれしかいえないんだな。
それにお前がここに常駐する意味はないよな。

記念パピコ

コマツも軍需だよね

１が書き込みしないと
恐ろしいほどさびれてんねｗ
１だけがＰＨＰでＯＯＰに興味があって
その興味を無理矢理に広めようとしてる
このスレの落胆ぶり見ればよくわかるｗｗｗ

PHPにかぎらず、「オブジェクト指向」が一般化したと言っても、実際にはライブラリ（フレームワークを含む）が
クラス化されて、プログラマはそれを使ってるという程度の話でしかないから、OOPそのものの話が盛り
上がらないのは、当然といえば当然。

WebProgで勢いあるのなんてくだすれぐらいだろ

何度も１のこと前向きにとらえようとしたけど
やはり1が何をしたいのかよくわからん

OOPの勉強じゃないの？

自称非営利団体の運営を本業に転換する難しさのバーチャル体験学習。
乗せられたボランティアからの不満が噴出。
ありがち。そして解散。ありがち。

私も１が必死にスレ継続させてる意味が？？？
営利団体なら意味はわかりますが

このスレ1年以上在るのに、 1 ◆SWtzLesEmM が書き込んだことがある日数って 16日だよ。
必死どころか、やる気があるのかと言いたい。

2007
02/23 02/24 02/27 02/28 05/12
06/12 07/06 07/11 07/26

2008
01/29 02/02 02/06 02/10 02/17
02/24 02/25

暇人乙

まー、ここで勉強するな、とは言わないけど、本気でやろうと思ってる人は、まず自分で本買うなりして勉強すると思うよ。

別に興味ないやつはスルーでも何でもしときゃいいと思う。

>>562
1自演乙！

自演度は THE END

保守

このスレで、今日から貴方もOOP！！！＼(^o^)／

>>1
オッパッピーの間違いですよね

保守

保守

難解も、難解も、オブジェクト指向

スレタイの主旨からずれるけど、
やはりC言語は、一度は学んでいた方が良いな。

Javaからプログラムに入ったから、PHPのOOPでアロー演算子使うのにとても違和感あったのだけど、
Cの構造体を知って、ドットシンタックスよりアロー演算子の方が正統派と思えるようになった。

どっと疲れる

どっと込む

>>573
>>574
バカアロー

諸事情により、Web系のプログラミングから離れていたけれど、
また時間がとれたら舞い戻ってきます。よろしくｗ

PHPに触る機会が・・・なんで、VBばっかりなんだ・・・

保守

保守

クラスの作り方（設計）について、考え方が参考になる本がありました。

http://www.amazon.co.jp/dp/4798110558/
モデルとプロセスをめぐる冒険

「モデリング」ということについて調べてみると、いろいろノウハウがあるようです。

保守

保守

保守

大手ECサイトのヨドバシドットコムが、サイトリニューアルから大規模な障害を3日間...
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php?qid=1220150877

506 ：目のつけ所が名無しさん：2008/10/26(日) 00:47:20
大手ＥＣサイトで、ここまで派手なリリース失敗は初めて見た。
エンジニア向けＩＴ情報誌や関連サイトは、ぜひ取材して原因を明かして欲し
いは。

保守

保守

定期的に保守してるの誰？
糞スレに対してその執念が怖いんだが。。。

お前の粘着質の方が怖い

PHP でオブジェクト指向の設計をするための 7 つの良い習慣を身につける
http://www.ibm.com/developerworks/jp/opensource/library/os-php-7oohabits/

PHP での適切な OO の習慣を身につけることによって、より安定していて、保守が容易で、拡張も容易にできるアプリケーションを作成することができます。そのためには、次のことを忘れないでください。

* 控え目である
* 良き隣人である
* メドゥーサを見ないようにする
* 結びつきを極力弱くする
* 結束性を高める
* 家族の一員として扱う
* パターンで考える

こうした習慣を身につけ、使いこなせるようになると、皆さんはきっとアプリケーションの品質が変わったことに驚くはずです。

内容は否定しないが、その書き方はどうかなと思うな。
英語の翻訳だからなのかな。
「メドゥーサを見ないようにする」なんて飛躍した比喩表現では
イメージつかないだろｗ

http://phpspot.org/blog/archives/2008/11/php_7_1.html
パクりblog乙

>>589
メデューサの項目でインタフェースを使う意義って何？
ファクトリーパターンの利点しか説明してないような気がするんだが

>>591
広告の方が多いってどうなんだよ
1:4で広告じゃねーか

DIコンテナとかどうなのか

オブジェクト指向のカンタンな例

<?php
class A
{
function foo()
{

echo 'hello <br>';


}
}



$a = new A();
$a->foo();

$b=new A();
$b->foo();



?>

簡易な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を参照するから。

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

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

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

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

は？

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

一応保守しておきます。

OOPのしっかりしてるFWどれ

FWは、その開発目的によるので、結論は出ない。
いや、あおりとかじゃなくて。

コードの参考になるのはどれかと

PHPのフレームワークでMVCのタイプを使ってみました。
同じ機能を作るのに、コードを書く量が少なくて済むと楽ですね！

ただ、MVCだとスクリプトのファイル数が多くなると、ゴチャゴチャして見づらいと思いました。
MVC以外のフレームワークでオススメのものはありますか？

http://www.slideshare.net/NetPenguin/mvc-2659370
・PAC
・RecursiveMVC（HMVC）
・MMVC
・Doc/View
という仕組みが紹介されていました。

特に無い

>>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/

人の書いた文章を全文コピペするのはどうかと思うよ

あ、上のは主に>>759に対してね

>>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^*)/

どのフレームワーク？

http://www.phppro.jp/school/oop/vol1/1
サイト見つけたので紹介しておきます。

オブジェクト指向ってrequire文とinclude文みたいな考えと同じかな？
必要なときにどこからでも呼び出せるプログラムみたいなものだよね。

うん

OOPの説明で一番わかりやすかったのがプレーヤーの例

プレーヤーを継承した CDプレーヤー，MP3プレーヤー がある
それぞれに 再生，停止，早送り，巻き戻し，次トラック，前トラック という機能(メソッド)がある

具体的な処理はそれぞれが行うので，使う人はプレーヤーの処理している内容を
理解している必要はなく，再生したいときに再生ボタンを押すという事だけ
分かっていればいい。(カプセル化)

つまり考え方であって，そういう意味では間違ってないのかもしれない。

それぞれにあるのではなく、プレイヤーという抽象クラスにあるのでは？

>>773
ダックタイピングなら、それぞれにあってもいいよね

OOPの説明でダックタイピングの例出すの？

>>773
そうなんだけど，具体的な実装がそれぞれ違うという意味で
ああいう書き方にした。

>>775
PHPは型にしばられない（しばられなさすぎて困る）スクリプト言語だからね。

逆に、静的言語のように型を意識しすぎると、スクリプト言語のメリットが少なくなると思う。

「じゃぁ、お前、クラス階層つかわねーのか？」と言われればノー
コンポーネント（レイヤ）の中では、型を意識し、拡張する場合は継承も使用する。
コンポーネント間の接続は型ではなくメッセージ（メソッド）に束縛させるように意識している。

でも最近は、interface作って、抽象クラス作ってというのがおっくうになってきたので、可能ならメソッドポインタによるコールバックで済ませちゃうこともしばしば。

Yiiブログチュートリアル　日本語訳
http://www.craftgear.net/docs/yii_blog_tutorial/index.html
本家の日本語訳が途中でストップしてるけど、こちらは全部訳してある。

本家
http://www.yiiframework.com/doc/blog/ja

保守しておきます。

javaや.NETはたまたPythonあたりの純血PGが書けばOOPっぽいソースになると思うよ。
PerlとかPHPから始めました、ってのはだめだな。

PHP6のオブジェクト指向ってなにか大きな変化ある？

遅延静的束縛とか
名前空間とか

名前空間は5.3だろ

遅延静的束縛もですが

機能追加がほとんどか。
じゃあ、PHP5のコードをPHP6に移植しても問題なく動くってことでいい？
PHP4→PHP5のときは大変みたいだったけど。
同じ思いをしたくない。

互換性見れば分かるだろ

逆に互換性なんかいいから関数の無茶苦茶な命名規則とか直して欲しい

関数はもうほうっておいて、
公式にオブジェクト指向ライブラリを提供すればよい

>>788
SPLって公式じゃないの？

質問するのが怖いんだけど、自分はフォームのパーツを呼び出すのに
オブジェクト指向（クラス）を使ってるつもりなんだけど正しいのか自信がない

クラスformPartsの中で各プルダウンやラジオボタンの要素（nameとvalue）を
外部ファイルから読み込んどいて
$fp = new formParts();
$pref = $fp->callPullDown('prefecture',$val);
$job = $fp->callPullDown('job',$val);
$sex = $fp->callRadioButton('sex',$val);

こんな感じでメソッドでパーツの種類を指定しつつ（ラジオボタンかプルダウンか）
そのパーツの要素（都道府県とか職業とか）と既定値（$val）を投げて呼び出してる。
プルダウン要素とかは各メソッド内部で引数によって外部ファイルから読みこんでる。

クラスってこんな使い方でいいの？　継承とかはさっぱりわからない、どういう状況で使うんだか。
あと1さん凄いね、ガッツがあるなぁ。。

OOではないな

分からないなら普通に勉強しろよ・・・

ツールの勉強する前に基本を勉強しろ

oopってさ
ＰＨＰ最大の武器であるＨＴＭＬとの親和性の高さを殺してるよね

なんで？

いまの流行はテンプレートだから
PHPのHTML埋め込みなんてもう古い

そんな流行もあったねぇ。今は違うよ。

kwsk

テンプレートってどんな利点があるの？
そもそも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

PHPでOOPやると重いと感じませんか？

いいんです！
コーディングが楽だから、OOPで良いんです！！

逆だろ
OOPだからボトルネックが把握しやすくてメンテナンスや新実装がしやすくなる

しかし、実行速度遅くなるね

遅くなるって体感でわかるほど遅くなるのか？
だったら書き方おかしいよ

>>810
体感できないとは幸せだね。

case by case.

>>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
ゴバクしただけあって、センス悪いな。

>>813

> MVCってユニットテストために
> ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。

正しいが、これは現場的な視点の１つの考え方。

MVCは、スケーラブルなサイト構築のためのパラダイムという方が、しっくりくると思うが...

新米PGに教える方法としては良いかもしれん

PHPのOOPフレームワークを教えて下さい。
イメージとしてはJavaのStrutsのようなものです。

JavaStrutsはさておき、おすすめはYIIだな。PHPの中では美しい。

>>818
YII以外では無いのでしょうか？
YIIはOOPフレームワークとしては不完全です。

>>819
どの辺が？

>>820
オブジェクト指向言語であればオブジェクトを使用するところで、
配列を使用する点。

>>821
なんでOOPフレームワークを使いたいの？

>>822
OOPに慣れてるからです。
オブジェクトとして定義するところで
phpの場合、配列になるのでいらいらします。
たとえばCakePHP。ModelがModelになっていない。
やはり後付けでOOP機能が加わった言語では無理があるのですね。

>>823
ModelがModelになってないというのは具体的にどういうこと？

>>824
どのオブジェクト指向言語を経験しましたか？
それにあわせて話をします。

>>823
phpで本格的なオブジェクト指向ははじめから無理だよ。

PHPのOOP自体、後付けだし...

>>825
Java

>>828
ぜひStrutsの話を聞きたいですね。
たとえばCakePHPやsymphonyとどう違いますか？

PHPのOOP関連機能が中途半端なのは当たり前。
実行速度が遅いPHPではそもそも向いていない。

>>829
話をすると言って聞くばかりなのはなんでだ？

>>831
Javaのフレームワークのことを教えてください

>>832
ModelがModelになってないというのは具体的にどういうこと？

>>833
Javaのフレームワークの比較で語りましから、あなたが今までにどのJavaフレームワークを使ってきたのか教えてください

いやです

>>835
無知の自慢するべきではない。
あなたは一生、PHPでOOPの真似やってた方がよい。

語りまし？
いやです

phpでOOPはダメぽ

いやです

完全にoopオリエンテッドな言語でしかoopしないって主張が、かなりダメぽ

phpは継ぎ接ぎだからoopに向いてない
速度の面でも不利

ダメな理由は遅いから。

>>834
答えられないなら最初から言うな見栄っ張りｗ

>>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の標準関数はどのクラスに属するのですか？

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

俺はゴミカスだがエリートゴミカスだ
お前らのような下級ゴミカスとは格が違う

『オレは本当はスゴいんだ』病 www

>>857
逆に女子はトイレ行ったら手を洗うの禁止な。

phpでOOPとは単なるアホ

じゃあOOPでphpするよ。

？
でも、よく言った！

Java WicketとかPHP Piece Frameworkに流行ってほしいな。
平たく言えば何でもセッションに突っ込んでるだけなんだけどね。

ここまでトレイトの話題無しかｗ

実際トレイトって、あれば便利な気はするけどどこで使うのか思いつかん。
だれか使いこなせてるって人いますか？

PHPはむしろトラッシュ

まだ5.4使える環境に出会ったことが無いわ

なんでもセッションでいいよな
PHPってそういうもんだろ

セッションハイジャックの脆弱性を可能な限り排除できるなら、
セッション利用でOK。

>>1
PHPでOOPかよw

PHPでOOPなど愚の骨頂

PHPなど愚の骨頂

3Pとか4Pがあるように00Pもあるのです

OOPチーズ

>>1
PHPでOOPはできねえよ

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での実例をどうぞ↓

カス言語PHPには無理

phpのオブジェクト指向機能はおもちゃ。

おもちはおもちや

https://www.google.co.jp/#q=php+oop
約 10,600,000 件 （0.13 秒）

PHPのオブジェクト指向入門 | オブジェクト指向PHP.NET
http://www.objective-php.net/&;amp;#8206;

php

>>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.net/test/read.cgi/tech/1393660194/88

メソッドを実行しなきゃどうってことはない

Formのクラス作ったら500行になっちゃった
これって糞プログラムの部類なのかな・・・
シンプルに書きたいのに機能付け加えていくとどうしても肥大化してしまう

美少女オブジェクトに排便しろというメッセージを飛ばすのか
胸が熱くなるな

ガベージコレクションは自動で実行されるものなので我々が命令するものではない

PHPでOOPなんてPOOP以外の何物でもない

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』 というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

TVD73U3V71

phpについて役立つ情報とか
http://mevius.5ch.net/test/read.cgi/tech/1557329831/l50

4Z0

見ろ！人ごみに流されて変わってゆく私を

もう少しで楽しい時間がやってくるかな？