PHPでOOP (894ﾚｽ)
上下前次1-新
609: 2008/12/17(水)04:51 ID:??? AAS
別にいいんじゃ？
610: 2008/12/17(水)10:09 ID:??? AAS
>>606見たんだけど、MVCってこんななの？
View や Model 1つに対して1ファイルみたいだけど、ファイル量半端ないことになりそう。
611: 2008/12/17(水)14:15 ID:??? AAS
DBの形式や最終的な見せ方によって、ファイル数は変わるんじゃないの？
でも、MVCってわりとファイル多めだよな！
1ファイルのコード量、大して多くないけど
612: 2008/12/17(水)15:06 ID:??? AAS
ファイルが多めなのが嫌なら１ファイル内に複数書けばいいじゃない
613: 2008/12/17(水)17:53 ID:??? AAS
OOPそのものをやろうとするとクラスやファイル量が多くなるからね。
汎用性を考えて作ろうとするとなおさらだ。それはしかたがないのかも。
そこをあえて、フレームワークや外部のモジュールなどを使わずに
非常にクラス数を少なくしてやってみたいなと思うんだけどね。
MVCの理解の一環として。
614: 2008/12/17(水)20:20 ID:??? AAS
やってみればいいのでは？
615: 2008/12/18(木)01:34 ID:??? AAS
<?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();
省12
616: 2008/12/18(木)01:36 ID:??? AAS
なんじゃそりゃ
617: 2008/12/18(木)01:37 ID:??? AAS
最後の一行間違い
618: 2008/12/18(木)08:21 ID:??? AAS
せめてクラスは３つ以上にするべきだろ。
最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで
出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく
なると思うんだけど。
619(1): 2008/12/18(木)10:48 ID:??? AAS
これはMVCどこがやるのが妥当か？
ってところで迷う。
時々、曖昧なのが出てきちゃう。
620(2): 2008/12/18(木)11:48 ID:??? AAS
>>619
ここで事例を通じて具体的な意見を交わしていけばどうかな？」
例えば・・・
掲示板
■コントローラ：処理の内容を判断するクラス
・プログラムが実行された時、一番最初に実行される
・POSTの値をみて、以下の処理にてどれに該当するかを判断する
・データを表示する
・データを書込む
・編集用のフォームを表示する
省7
621(1): 2008/12/18(木)12:24 ID:??? AAS
>>620
『■コントローラ：処理の内容を判断するクラス 』の
> ・データを表示する
> ・データを書込む
『 ■モデル：データファイルを管理するクラス 』の
> ・ファイルの読み込み、書込みをする
って、意味が重複しているような感じがするのですが...
ならば、
■コントローラ：処理の内容を判断するクラス
・モデルからデータを受け取る
省2
622: 2008/12/18(木)12:52 ID:??? AAS
>>621
>>620じゃないけど。
・データを表示する
・データを書込む
・編集用のフォームを表示する
実際に上記の作業をするのは View と Model だよ。Controllerがするわけじゃない。
コントローラーはどれがリクエストされたかを判断して、適切な Model と View を呼び出す。
623: 2008/12/18(木)16:39 ID:??? AAS
>>469は具体的に何処のコードを批判しているのかが分からないので
どなたか解説を頼みます。
624(2): 2008/12/18(木)20:10 ID:??? AAS
MVCモデルでM同士で連携することってあり？
それとも必ずC経由？
C経由の場合、Mをなるべく疎結合になるように細分化してると、
Cの各Actionに書くロジック量が半端なく多くなってくるんだよね。
（Aデータを取ってきてBデータを取ってきてBをCバリデータに通してAとBを基にDを作成して・・・みたいな）
一つのAction内にロジックが増えるのもどうかと思うし、それって新しいモデルじゃんという気もしてこないでもない。
625: 2008/12/18(木)20:23 ID:??? AAS
>>624
俺はM同士で連携するかたちでも良いと思うけどね。
CからMを見た場合、あるまとまった処理単位でメソッドを呼び出す形であることが
重要だと思うから。
CがMを使うときは必ずメソッドＡ呼び出してメソッドＢ、メソッドＣを実行しなければならない。
さらに、そういう３連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが
悪くなると思うから。
626(1): 2008/12/19(金)16:35 ID:??? AAS
試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。
627: 2008/12/19(金)19:23 ID:??? AAS
>>626
うｐきぼん
628: 2008/12/20(土)14:28 ID:??? AAS
>624
変化する内部状態を持つモデル同士で連携させると見通しが悪くなる。
生成してから、（観察される）内部状態が変化しないようなモデルはどこから呼んでもそれほど大きな問題はない。
オブジェクトの生成期間中に（観察される）内部状態が変化するようなモデルは、C直轄にしといた方がいい。
629: 2008/12/20(土)14:34 ID:??? AAS
生成期間→生存期間
なんか寝ぼけてた。
要は変化する「状態」を持っているもの全てはCの管理下に置いておいた方がいいってこった。
「状態」が無いもの（生成時にファイルからデータをロードしてそれっきり、とか）はどこにあったって構わない。
インスタンスの生成を行なうクラスは自分ルールでもいいからある程度絞っておかないと混乱すると思うけどな。
630(2): 2008/12/20(土)15:34 ID:??? AAS
変な質問だけど、OOP での Validator ってのがよくわかんねえ。
is_numeric(); とかをModel内にべた書きしないで、Validatorオブジェクトを通じて、変数の内容を確認すればいいの？
$str = 'string';
$valid =& new Validator();
$valid->isStr($string);
みたいな感じで。
BaseValidator みたいな基本的なチェックをするクラスを作って、継承した先で複雑なチェック用のメソッドを実装させればいいのかな。
631: 630 2008/12/20(土)15:37 ID:??? AAS
引数間違えてる。最後の行。
$valid->isStr($str);
ね。まぁ、別に問題ないが。
632: 2008/12/20(土)15:54 ID:??? AAS
問題はありまくりだろ
633(2): 2008/12/20(土)16:42 ID:??? AAS
>630
外部ﾘﾝｸ:gist.github.com
俺はValidatorクラスはコントローラ単位で実装してる。「入力値の検証」なのだから、コントローラの責任。
Validatorだけ独立させるのはコードの見通しを良くするためであり、責任はあくまでコントローラにある。
ただ、実際にそっからコールするのはModelのメソッド。何が許可されるかを知ってるのはだいたいModelだからな。
たとえば受け付ける値が日付なら、そっから日付クラスのvalidateメソッドを呼び出す（MyDate::validate($string)）。
POSTされる中に列挙型（<select>から送られるような、選択肢が限られているもの）とかがあった場合にこの構成は滅茶苦茶強い。
<select>のためのデータ生成とか、送られたvalueから画面表示用の文字列（「〜モード」とか）への変換を一箇所に集められる。
あと、文字列が決まったフォーマットになっているか調べる場合とかな。
is_strとかctype_stringとかstrlenだけで検証が終わるものはvalidatorクラス内に直書きする。
省1
634: 2008/12/20(土)17:07 ID:??? AAS
>>633
ものすごく丁寧にありがとう。
まだぼんやりとしかわからないけど、サンプルコードを読み解いて、いろいろ試してみる。
635(1): 2008/12/20(土)17:13 ID:??? AAS
>>633
>「入力値の検証」なのだから、コントローラの責任。
「検証する」んじゃなく「検証させる」のが仕事じゃないの？
ここでいう入力値の検証って例えばどんなこと言ってる？
3行目で
>何が許可されるかを知ってるのはだいたいModelだからな。
って書いてるってことは、なにか、Modelに関係ないものを想定してると思うんだけど。
636(1): 2008/12/20(土)18:07 ID:??? AAS
>635
大雑把に言うと、処理を始める前に可能なパラメータの検証全般。
純粋に入力値だけを見て判定できるものだな。システムや環境の状態を見なくとも判定できるエラーを出す役割。
処理を始めないと分からないもの（DBに指定されたエントリーがあるかとか）は、バリデーションでは扱わない。
DBにこの値があった場合はクッキーにこれが無いといけない…みたいなのも対象外。
日付として「'9999-12-31'」が指定されてもバリデーションでは引っ掛けない。これは有効な入力。
「'2008-13-45'」はバリデーションでエラーとして引っ掛ける。この日付が有効になる事はあり得ないから。
メールアドレスが正しいフォーマットかをチェックするのはバリデーションで、それが有効なメールアドレスかをチェックするのはモデル。
ユーザーIDとして正しいフォーマットならばバリデーションは通るが、当該ユーザーがいない場合モデルがエラーを出す。
637(1): 2008/12/21(日)00:53 ID:??? AAS
>>636
なんとなく分かるけど、
例えばそれだと「2008-13-45は日付(のつもり)」ってことを
コントローラが知っとかないといけないってことだよね？
あと、日付が必要なくなった、とかいうときは
コントローラーを変更しないといけないってことにならない？
なんか拘ってるようでアレだけどお勉強スレってことで許してｗ
638(1): 2008/12/21(日)00:57 ID:??? AAS
って、もしかして、リクエストとして渡ってくるものを想定してるのかな。
hoge.php?date=20081231
とか。
639(1): 2008/12/21(日)12:32 ID:??? AAS
>637
「コントローラ」の指している範囲が俺と違う気がする。
俺はディスパッチャ（処理の振り分け）部分じゃなくて、そこから振り分けられる先のコントローラを指している。
ぐぐったが、「アクション」としてクラスにして丸ごとコントローラから切り離す文化圏もあるようだな。
「日付のつもりで送られてくる文字列がある」という事実は、ディスパッチャは（たいていの場合）知らない。
が、コントローラ（アクション）は知っている。だって知らないと日付具象モデルに処理を引き渡しようがないからな。
Cにはどの道変更が入る。リクエストをモデルに引き渡すのが仕事だからな。
「日付がどこからどう渡ってくるか」はCの管轄であってMじゃない。Mはそれを知っていてはいけない。
Mは「日付を渡されたらどうする」だけ知っていればよく、実際問題どこに日付があるかはCが隠蔽すべき。
たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
省3
640: 2008/12/21(日)12:37 ID:??? AAS
まあ実際は、日付省略時のMの挙動を変えるだろうけどな。
>638
入力値以外のもの（DB内の値とか処理結果）の検証は当然モデル。
というか、そういうのは一般にはバリデーションとは言わずアサーションと呼ぶ。
641(1): 2008/12/21(日)13:45 ID:??? AAS
>>639
Cは振り分けだけが仕事だと思ってたんだけど。
その先にさらに C があることなんてあるのか。
サブコントローラーみたいな感じ？
642(3): 2008/12/21(日)14:51 ID:??? AAS
>641
やっぱ、そこか。
例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。
で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。
で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。
これをMVCのうち、MとCのどっちに置くかの問題。
MVC、MVCって言ってるけど、本質的には4層なんだよ。
処理の振り分けに1層を割くならば、4層なくてはならない。
処理の振り分け=呼び出すCの決定（ディスパッチャ）→どのMを呼び出すかを制御する（コントロール）
→データを実際に扱う（モデル）→表示（ビュー）、となる。
省4
643: 2008/12/21(日)15:35 ID:??? AAS
>>642
>たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
>この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
これって制御じゃなくてロジックだからモデル的仕事じゃねぇの？
644: 2008/12/21(日)16:01 ID:??? AAS
>>642
横槍で質問してすまんかった。
すげーわかりやすい。
勉強になった。ありがとう。
645(1): 2008/12/21(日)16:03 ID:??? AAS
4層ｗｗｗ
646: 2008/12/23(火)01:41 ID:??? AAS
>>645
あなたの顔に死相が出ていますよ。4層だけに。
647(1): 2008/12/24(水)12:54 ID:??? AAS
考え方としてディスパッチとコントロールは分けるべきだが、
実装するときは、コントロールで括るよな？
648(1): 642 2008/12/24(水)22:47 ID:??? AAS
>647
M・V・Cで分けるならCってのは同意。いちおう
> 処理の振り分けに1層を割くならば
と予防線は張ってあるわけだが。
俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。
649: 2008/12/25(木)12:55 ID:??? AAS
>>648
> Controllerの親クラスとかControllerFactoryでディスパッチする事が多い
ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの？
650: 2009/01/04(日)21:25 ID:??? AAS
保守
651: 2009/01/10(土)18:38 ID:??? AAS
保守
652: 2009/01/18(日)01:35 ID:??? AAS
手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。
653: 2009/01/26(月)20:14 ID:??? AAS
お？サンプルか？
654: 2009/02/02(月)14:37 ID:JcAer1H1(1) AAS
勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。
自作のモチベ下がっちまったい。
655: 2009/02/02(月)14:46 ID:??? AAS
自作する理由は楽するためじゃないだろう
656: 2009/02/02(月)14:54 ID:??? AAS
もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい
657: 2009/02/02(月)15:06 ID:??? AAS
元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。
で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。
658: 2009/02/02(月)20:06 ID:??? AAS
凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ
659: 2009/02/03(火)00:06 ID:??? AAS
まぁ、たぶんそんな感じ。
要するにフレームワークの魅力に気付いたわけですよ。
660: 2009/02/03(火)01:52 ID:??? AAS
先に気づいてからやれば良かったな
661: 2009/02/04(水)08:03 ID:??? AAS
そういうのは簡単に気づけないだろう。
プログラムは体感して分かっていくものなのだから。
662(1): 2009/02/04(水)21:38 ID:??? AAS
俺としては魅力に気付けただけでも大きな進歩だ。
自作云々は別にして。
663: 2009/02/05(木)22:29 ID:6GWaaOT6(1) AAS
あけおめ
664: 2009/02/06(金)07:54 ID:??? AAS
では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ？
PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。
665: 2009/02/07(土)01:12 ID:??? AAS
>>4
宣伝乙
666: [age] 2009/02/09(月)20:26 ID:??? AAS
えらく昔の書き込みにレスしてるな。
667(2): [age] 2009/02/12(木)07:33 ID:??? AAS
フレームワークの魅力についてまとめてみるか？
668: 2009/02/12(木)09:08 ID:??? AAS
どうぞ
669: 2009/02/12(木)15:59 ID:??? AAS
>>667
wikiにしてもらえるなら俺も手伝う
670: [age] 2009/02/12(木)20:11 ID:??? AAS
いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る
671: 2009/02/12(木)20:25 ID:??? AAS
なぜにフレームワークの魅力をまとめようと？
672: 662 2009/02/12(木)20:56 ID:??? AAS
>>662 ≠ >>667
だからね。
俺は人に語れるほどまだ理解してないから。
673: 2009/02/12(木)20:59 ID:??? AAS
なんだ教えて君か
674: [age] 2009/02/12(木)21:37 ID:??? AAS
おまえもな
675: 2009/02/12(木)22:00 ID:??? AAS
サポートするといってるんだから、教えてじゃないだろｗ
676(1): 2009/02/13(金)20:54 ID:??? AAS
外部ﾘﾝｸ:q.hatena.ne.jp
677: 2009/02/15(日)23:40 ID:??? AAS
>>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの
メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。
678: 2009/02/16(月)00:05 ID:??? AAS
一問一答形式でwikiでも作るか
679: 2009/02/16(月)00:44 ID:??? AAS
visualstudioが優秀すぐる
680(1): 2009/02/16(月)11:09 ID:IOY0ae9e(1) AAS
Java とか C#やったほうが飲み込みは早くなるのかな。
でも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。
681: 2009/02/16(月)19:31 ID:??? AAS
>>680
いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。
なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。
682: 2009/02/16(月)23:33 ID:??? AAS
ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。
ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。
683(1): 2009/02/17(火)12:38 ID:??? AAS
でも、perlってすぐ忘れちゃうよな...
684: 2009/02/17(火)20:53 ID:??? AAS
>>683
それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。
685: [age] 2009/02/23(月)20:40 ID:??? AAS
PHP では OOP を学べないという意見があるが、結論だけ
いうのではなく、その理由の部分を述べていくといいかもね。
686: 2009/02/23(月)21:35 ID:??? AAS
別に学べるのでは？
687: 2009/02/23(月)22:27 ID:??? AAS
ん、どこかにPHPでは学べないと書いてあるのかな？
個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。
688: 2009/02/23(月)23:55 ID:??? AAS
オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。
689(1): 2009/02/24(火)02:09 ID:??? AAS
出る幕はあると思うが、最終的にフレームワークを構築することになると思う。
いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。
また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。
690: 2009/02/24(火)12:23 ID:??? AAS
WEBアプリでもActionScript3なら、バリバリOOPだYO!
691(1): 2009/02/24(火)12:40 ID:??? AAS
まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。
692(1): 2009/02/24(火)19:41 ID:??? AAS
>>691
エンタープライズならそんなケースいくらでもあるだろｗ
693(1): 2009/02/24(火)20:31 ID:??? AAS
>>689
俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。
694: 2009/02/24(火)20:35 ID:??? AAS
>>693
ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが
695: 2009/02/25(水)06:21 ID:??? AAS
>>692
聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。
696: 2009/02/26(木)22:25 ID:??? AAS
クライアントマシンの性能がこれだけアップしているのに、
クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかｗ
697(1): 2009/02/26(木)23:57 ID:??? AAS
ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって
性能うんぬんは考えてないんだよな
698(2): 2009/02/27(金)00:54 ID:??? AAS
勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい
699: 2009/02/27(金)05:45 ID:??? AAS
つーか開発効率は性能に含まれるだろう
700: 2009/02/27(金)06:00 ID:??? AAS
は？
701: 2009/02/27(金)13:31 ID:??? AAS
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:???
つーか開発効率は性能に含まれるだろう
省2
702: 2009/02/27(金)13:31 ID:??? AAS
>>698
性能を求めるならフレームワークなんて使うなって話
703(1): [age] 2009/02/27(金)19:50 ID:??? AAS
>>698が言ってる「性能」って何？
これは釣りなのか？
704: 2009/02/27(金)20:00 ID:??? AAS
「やあ、とりあえず性能の一番いいやつを一つくれないか。」
「今日はCakePHPがお勧めとなっております。」
「じゃあ、そいつをくれ。」
「かしこまりました。」
705(1): 2009/02/27(金)20:35 ID:??? AAS
>>703
なんで俺に絡むんだよ。
たった1個上のレスも読めないのか？
釣りなのか？
706: 2009/02/28(土)01:39 ID:??? AAS
>>705
何言ってるんだ？
1個上のレスを読んでるから性能って何って話だよな
707: 2009/02/28(土)02:02 ID:??? AAS
>>697に聞いてくれよ
俺は知らんよ。
使われた言葉返しただけなのにｗ
708: 2009/02/28(土)04:26 ID:??? AAS
1ファイルにphp+html+css+jsべた書きが催促
上下前次1-新書関写板覧索設栞歴
あと 186 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s