PHPでOOP (894ﾚｽ)
上下前次1-新
545(1): 2008/02/25(月)13:44 ID:??? AAS
アフィリエイト見てオナニスレてことに確信がもてたよ
このスレは１の自己満足以外に何も生まれないよ結果としてね
546: 2008/02/25(月)13:45 ID:nYfgU4lL(1) AAS
>>543-544
何で君はスルーができないの？
誰も書き込まなければそのまま消えていくんじゃないの？
547(1): 2008/02/25(月)13:46 ID:??? AAS
コテハン使って自慢げにソースコード公開するやつは
よほど腕に自信がある奴か
初心者相手に自己満足したい奴かのどっちか
548: 2008/02/25(月)13:47 ID:??? AAS
>>545
君の語りを見てオナニレスてことに確信がもてたよ
これらのレスは君の自己満足以外に何も生まれないよ結果としてね
549: 2008/02/25(月)13:49 ID:??? AAS
>>547
ああ、そうか。だったら君はもう来るな。
550(1): 2008/02/25(月)13:52 ID:??? AAS
１が名無しとなって言い訳してるくさいな
551: 2008/02/25(月)13:54 ID:??? AAS
>>550
俺は１じゃないんだけどな。言い返せなくてそれしかいえないんだな。
それにお前がここに常駐する意味はないよな。
552: 2008/02/25(月)13:58 ID:??? AAS
記念パピコ
553: 2008/02/25(月)14:52 ID:??? AAS
コマツも軍需だよね
554: 2008/02/25(月)17:26 ID:??? AAS
AA省
555: 2008/02/26(火)10:28 ID:??? AAS
１が書き込みしないと
恐ろしいほどさびれてんねｗ
１だけがＰＨＰでＯＯＰに興味があって
その興味を無理矢理に広めようとしてる
このスレの落胆ぶり見ればよくわかるｗｗｗ
556: 2008/02/26(火)12:06 ID:??? AAS
PHPにかぎらず、「オブジェクト指向」が一般化したと言っても、実際にはライブラリ（フレームワークを含む）が
クラス化されて、プログラマはそれを使ってるという程度の話でしかないから、OOPそのものの話が盛り
上がらないのは、当然といえば当然。
557: 2008/02/26(火)14:01 ID:??? AAS
WebProgで勢いあるのなんてくだすれぐらいだろ
558: 2008/02/27(水)22:15 ID:??? AAS
何度も１のこと前向きにとらえようとしたけど
やはり1が何をしたいのかよくわからん
559: 2008/02/28(木)00:08 ID:??? AAS
OOPの勉強じゃないの？
560: 2008/03/01(土)01:04 ID:??? AAS
自称非営利団体の運営を本業に転換する難しさのバーチャル体験学習。
乗せられたボランティアからの不満が噴出。
ありがち。そして解散。ありがち。
561: 2008/03/02(日)15:48 ID:??? AAS
私も１が必死にスレ継続させてる意味が？？？
営利団体なら意味はわかりますが
562(1): 2008/03/02(日)16:50 ID:??? AAS
このスレ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
563: 2008/03/02(日)20:21 ID:??? AAS
暇人乙
564: 2008/03/02(日)23:43 ID:??? AAS
まー、ここで勉強するな、とは言わないけど、本気でやろうと思ってる人は、まず自分で本買うなりして勉強すると思うよ。
別に興味ないやつはスルーでも何でもしときゃいいと思う。
565: 2008/03/09(日)10:19 ID:??? AAS
>>562
1自演乙！
566: 2008/03/10(月)14:48 ID:??? AAS
自演度は THE END
567: 2008/03/17(月)07:13 ID:??? AAS
保守
568: 2008/03/28(金)02:04 ID:??? AAS
このスレで、今日から貴方もOOP！！！＼(^o^)／
>>1
オッパッピーの間違いですよね
569: 2008/04/20(日)09:34 ID:??? AAS
保守
570: 2008/05/24(土)06:41 ID:??? AAS
保守
571: 2008/06/16(月)13:47 ID:??? AAS
難解も、難解も、オブジェクト指向
572: 2008/06/17(火)12:52 ID:??? AAS
スレタイの主旨からずれるけど、
やはりC言語は、一度は学んでいた方が良いな。
Javaからプログラムに入ったから、PHPのOOPでアロー演算子使うのにとても違和感あったのだけど、
Cの構造体を知って、ドットシンタックスよりアロー演算子の方が正統派と思えるようになった。
573(1): 2008/06/17(火)13:01 ID:??? AAS
どっと疲れる
574(1): 2008/06/17(火)16:56 ID:??? AAS
どっと込む
575: 2008/07/01(火)00:56 ID:??? AAS
>>573
>>574
バカアロー
576: 2008/07/27(日)23:15 ID:??? AAS
諸事情により、Web系のプログラミングから離れていたけれど、
また時間がとれたら舞い戻ってきます。よろしくｗ
577: 2008/08/09(土)20:52 ID:??? AAS
PHPに触る機会が・・・なんで、VBばっかりなんだ・・・
578: 2008/08/19(火)00:44 ID:??? AAS
保守
579: 2008/08/28(木)21:10 ID:??? AAS
保守
580: 1 ◆SWtzLesEmM 2008/09/02(火)15:51 ID:w90kCMMO(1) AAS
クラスの作り方（設計）について、考え方が参考になる本がありました。
外部ﾘﾝｸ:www.amazon.co.jp
モデルとプロセスをめぐる冒険
「モデリング」ということについて調べてみると、いろいろノウハウがあるようです。
581: 2008/09/27(土)22:23 ID:??? AAS
保守
582: 2008/10/06(月)00:30 ID:??? AAS
保守
583: 2008/10/24(金)23:26 ID:??? AAS
保守
584: yodobashi 2008/10/26(日)01:15 ID:??? AAS
大手ECサイトのヨドバシドットコムが、サイトリニューアルから大規模な障害を3日間...
外部ﾘﾝｸ[php]:detail.chiebukuro.yahoo.co.jp
506 ：目のつけ所が名無しさん：2008/10/26(日) 00:47:20
大手ＥＣサイトで、ここまで派手なリリース失敗は初めて見た。
エンジニア向けＩＴ情報誌や関連サイトは、ぜひ取材して原因を明かして欲し
いは。
585: 2008/11/05(水)20:43 ID:??? AAS
保守
586: 2008/11/13(木)23:12 ID:??? AAS
保守
587: 2008/11/15(土)09:19 ID:??? AAS
定期的に保守してるの誰？
糞スレに対してその執念が怖いんだが。。。
588: 2008/11/23(日)22:46 ID:??? AAS
お前の粘着質の方が怖い
589(1): 2008/11/29(土)11:22 ID:??? AAS
PHP でオブジェクト指向の設計をするための 7 つの良い習慣を身につける
外部ﾘﾝｸ:www.ibm.com
PHP での適切な OO の習慣を身につけることによって、より安定していて、保守が容易で、拡張も容易にできるアプリケーションを作成することができます。そのためには、次のことを忘れないでください。
* 控え目である
* 良き隣人である
* メドゥーサを見ないようにする
* 結びつきを極力弱くする
* 結束性を高める
* 家族の一員として扱う
* パターンで考える
省1
590: 2008/11/30(日)22:51 ID:??? AAS
内容は否定しないが、その書き方はどうかなと思うな。
英語の翻訳だからなのかな。
「メドゥーサを見ないようにする」なんて飛躍した比喩表現では
イメージつかないだろｗ
591(1): 2008/11/30(日)23:12 ID:??? AAS
外部ﾘﾝｸ[html]:phpspot.org
パクりblog乙
592: 2008/12/01(月)12:13 ID:YUzphIUV(1) AAS
>>589
メデューサの項目でインタフェースを使う意義って何？
ファクトリーパターンの利点しか説明してないような気がするんだが
593: 2008/12/02(火)01:29 ID:??? AAS
>>591
広告の方が多いってどうなんだよ
1:4で広告じゃねーか
594: 2008/12/04(木)18:30 ID:??? AAS
DIコンテナとかどうなのか
595: 2008/12/14(日)06:43 ID:??? AAS
オブジェクト指向のカンタンな例
<?php
class A
{
function foo()
{
echo 'hello <br>';
}
}
$a = new A();
省4
596: 2008/12/15(月)02:03 ID:??? AAS
簡易なMVCモデルのサンプルってないのかなぁ。
フレームワークを作るとか、フレームワークを使うとかじゃなくてさ。
考え方を学ぶためにみてみたいんだけど。
過去ログにあるように、つい、MVモデルになってしまうもんで。
597: 2008/12/15(月)03:35 ID:??? AAS
巷に星の数ほどあるだろ
598: 2008/12/15(月)12:27 ID:??? AAS
Googleで、
簡易なMVCモデル
と検索させる
外部ﾘﾝｸ:www.google.com簡易なMVCモデル&ie=UTF-8&oe=UTF-8
ドゾ...
599: [age] 2008/12/16(火)10:49 ID:??? AAS
結構前の話だけど、>>488-489へのレスってついてるのかな？
過去ログ読み直してみても、何処が批判されているのかが分からん。
Viewはこれでいいと思うのだが。
600: [age] 2008/12/16(火)10:56 ID:??? AAS
外部ﾘﾝｸ[php]:www.zend.co.jp
ひょっとして、「Viewではhtml出力をしてはいけない」という考えを示している
ということなのか？
html出力は別のクラスに任せるべきで、Viewはそのクラスのインスタンスの生成
と実行までを行うべきだという視点で批判してるとか。
601(1): 2008/12/16(火)11:17 ID:??? AAS
はい？批判ってどれ？
602: [age] 2008/12/16(火)12:52 ID:??? AAS
>>601
批判している書込みは>>479です。
「に」のサンプルが、（コーディングにかかわるルール以外で）
MVCの設計はこれで良いのかがあいまいなまま終わってる気がします。
603: 2008/12/16(火)13:03 ID:??? AAS
気になってる批判は>>469もだな。そして>>471となっているが、そのレスが
無くておわってないかい？
604: 2008/12/16(火)19:38 ID:??? AAS
よくわかんないんだけど、OOPとMVCって両立できるの？
605: 2008/12/16(火)19:50 ID:??? AAS
MVCをOOPで実現するんだろｗ
606(1): 2008/12/17(水)01:23 ID:??? AAS
これどうなの？
外部ﾘﾝｸ[html]:www13.plala.or.jp
607: 2008/12/17(水)01:36 ID:??? AAS
どうって何が？
608: 2008/12/17(水)03:42 ID:??? AAS
MVCだと必ずフレームワークを使わなければならないわけでもないよね。ちがうの？
それとも、非常に単純なクラス構成でMVCを実現しようという考えが間違いとか？
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
横槍で質問してすまんかった。
すげーわかりやすい。
勉強になった。ありがとう。
上下前次1-新書関写板覧索設栞歴
あと 250 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s