PHPでオブジェクト指向プログラミング
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/04/17(日) 16:55:57ID:iM4mgYnJPHPによるOOPについて語りましょう。
0243239
2005/06/16(木) 21:43:06ID:???独学の悲しさか何がわからないのかわからない程混乱してます。
もっとシンプルな例えとして「部署一覧」や、「部署コードから部署名」を検索する場合、
・部署一覧クラス（部署単体クラスの集まりをデータにもつ）
・部署クラス（部署単体のクラス）
・DBクラス（DBへアクセスしてSQLを実行する）
が必要かなと思うのですが（間違ってますでしょうか？）
■DBクラスのSQLを実行するfunction query($sql)は
何を返すべきなんでしょう。
1.部署オブジェクトの配列（さらに部署一覧オブジェクトに読み込む）
2.部署一覧オブジェクト
3.部署名の配列。それを改めて部署オブジェクトに読み込む（さらに
部署一覧オブジェクトに読み込む）
4.部署名の配列。それを部署一覧オブジェクトに読み込む。
■部署一覧を取得するfunction bushoList()と、部署名を検索するfindBusho($key)は
1.両方とも部署一覧クラスのメンバにする
もし該当部署がひとつしかなくても配列がひとつしかないとして処理する
2.findBusho($key)がひとつしかないことがわかっていれば
bushoList()は部署一覧クラス・findBusho($key)は部署クラスのメンバにする
3.両方とも部署クラスのメンバにして、複数の部署名の場合に
部署一覧オブジェクトを生成してそれに入れ込む。
なにを悩んでいるかわかっていただけますでしょうか。
エスパー能力をあてにしてすみません、お願いします。
多分、
>>241
細かくする理由が無い場合、どういうクラスにしたらいいのかわからないです。
>>242
読んでは捨て読んでは捨てというのは具体的にどうしたらいいのか
わからないです。
単純に請求書一覧を得るとか部署一覧を得るとかなら配列を使うなりして
できるのですが、オブジェクト指向だとどうするのかがさっぱりです。
0244nobodyさん
2005/06/16(木) 22:42:39ID:???> ■DBクラスのSQLを実行するfunction query($sql)は何を返すべきなんでしょう。
1〜4のどれでもいいのではないかと。データの内容や量、処理の内容によって
どれを選ぶかもプログラマの腕にかかってるわけで。
あと、DBオブジェクトとデータにアクセスするオブジェクトは別々に設計した方がいいのではないかと。
> ■部署一覧を取得するfunction bushoList()と、部署名を検索するfindBusho($key)は
自分だったらDBクラスを持った部署データを専門に扱う「人事課」みたいなオブジェクトを作るかな。
$jinji = new jinji();
$bushoList = $jinji->bushoList();
$bushoList2 = $jinji->findBusho('shomu');
bushoListやfindBushoが何を返すかは最初の疑問の答えを参照。
> 読んでは捨て読んでは捨てというのは具体的にどうしたらいいのか
例えば、検索結果を全部一度に配列にぶちこむのではなく、ループの中で
1つの変数に1レコードずつ結果を代入して処理する。ループが回るごとに
その変数は上書きされるから配列にぶちこむのに比べてメモリを食わない。
0245nobodyさん
2005/06/16(木) 23:30:18ID:???クラスに関数をまとめるだけで十分だよ。
オブジェクト指向の勉強するなら、JavaとかRubyとかにした方がいい。
0246nobodyさん
2005/06/16(木) 23:47:48ID:???大規模開発になると避けて通れなくなるよ。PHPのなんちゃってオブジェクト指向でも
利用する価値はある。
最近、「クラスに関数まとめるだけ」で適当に作ったサイトがつぎはぎで巨大化するにつれ
保守が間に合わなくなって破綻したのでなんとかしてくれっつー依頼が多い。
まあ逆にフレームワークとかテンプレートエンジンとか詰め込みすぎて負荷でパンクした
サイトも知ってるけど。
> オブジェクト指向の勉強するなら、JavaとかRubyとかにした方がいい。
これは同意。
0247nobodyさん
2005/06/16(木) 23:50:59ID:???0248nobodyさん
2005/06/17(金) 00:02:32ID:???PHPのよさは手軽にかけることなんだから。
0249nobodyさん
2005/06/17(金) 00:06:10ID:???0250239
2005/06/17(金) 00:11:43ID:???つ、ついていけない…。「これ以上どうやさしく説明すればいいんだよ」
と怒られそうですが。（丁寧に説明いただいてるは語感からわかります。
感謝です。）
■DBオブジェクトとデータにアクセスするオブジェクトって
どう違うものなのでしょうか？（あ、何か日本語も変だ）
■人事課オブジェクトを作るというのは…
今回の程度の場合、細分化して部署クラスとかを作るんじゃなくて、
（例えばそれはデータメンバの変数にしたりして）操作するクラスを
つくるという解釈でいいでしょうか。
クラスにするものの勘所が全然つかめない…。
0251nobodyさん
2005/06/17(金) 00:23:58ID:???PHPでも工夫すればオブジェクト指向開発できるって言っても、そんな不毛な工夫するより、その言語に適した開発アプローチを取るべきだと思う。
0252239
2005/06/17(金) 00:27:02ID:???>>247
「したいぜ」というか「してみたいぜ」です。みなさんは、「できるけど
やらない。」なのでしょうけど、私は「できない」のでやり方は知って
おきたいのです。
何をクラスにするのかは、案件によって違ってくるんでしょうけど、
なんというか、こう常套手段のようなものを例示してもらえないかなと
思ってるんですよ。例えばDBがあって、そこからデータを引っ張ってきて
そのデータを扱うという操作についてとか…。デザインパターンと実際の
（この例みたいなの）が結びつかないんです。
面と向かって尋ねられる人がいればもう少し理解がはやいのかなとも
思うのですがいないもので。
0253nobodyさん
2005/06/17(金) 00:34:44ID:???0254nobodyさん
2005/06/17(金) 01:16:39ID:???とりあえず、DBへアクセスして結果を取得するクラスに関しては自作するより
PEAR::DBを使うことをおすすめする。
0255nobodyさん
2005/06/17(金) 02:48:28ID:???>こう常套手段のようなものを例示してもらえないかなと
常套手段のサンプルコードとかは、巷ではPHPよりJAVAの方がずっと多いんじゃないかな。
だからちょっとがんばってJAVAやってみるのも勘所をつかむにはいいかも。
あと私見だけど、自分でクラスつくるときには、
クライアント側（class Bushoを書く側ではなくnew Bushoってやったりメソッド呼び出す側）
の人にとってどうしたら便利か考えながらやるのがいいと思う。
今の段階ではクライアントにあたるのも自分自身だろうから、よりいっそう自分の欲望に正直にできるはず。
0256255
2005/06/17(金) 02:53:13ID:???>>243の前半の質問の答えは>>244の言うとおり、何がやりたいかに応じてどれでもいいと思う。
後半のに関してはfindBusho()を部署一覧クラスのメンバにして
$list = new BushoList();
$kikaku = $list->findBusho('企画');
って感じで使用したらいいんじゃないかと。
もしfindBushoが部署クラスのメンバだったら
$soumu = $kikaku->findBusho('総務'); // !?
って感じで、特定の部署から他の部署を検索（？）みたいで意味不明かなと思った。
bushoList()メソッドの使いどころは、おいどんにはよくわからんとです。
まあとにかく「クライアント側でどう使ったらいいか」をよく考えてみて。
応援してるからガンガレ！
0257nobodyさん
2005/06/17(金) 03:19:33ID:???PHP5のオブジェクト指向はかなりJavaを意識して作られてると思うんだけど
それでもやっぱり物足りない感じですかね？
0258nobodyさん
2005/06/17(金) 03:28:16ID:???0259nobodyさん
2005/06/17(金) 07:29:07ID:???どーれ試しに。。。
$obj = new MyClass();
と
$obj = & new MyClass();
の違いって何ですか？
0260nobodyさん
2005/06/17(金) 07:38:56ID:???0261nobodyさん
2005/06/17(金) 07:57:27ID:???PHP5でやったらStrict error
Strict Standards: Assigning the return value of new by reference is deprecated in C:\home\php\test.php on line 5
0263nobodyさん
2005/06/17(金) 08:29:16ID:???0264nobodyさん
2005/06/17(金) 09:30:34ID:???> ■DBオブジェクトとデータにアクセスするオブジェクトってどう違うものなのでしょうか？（あ、何か日本語も変だ）
DBオブジェクトってのはデータベースに直接アクセスするモノでしょ？
どんな命令でもquery関数に渡せば実行しちゃうような。
それだとqueryに変なモノを渡された時に困るので、DBオブジェクトは直接
使わないようにして、queryを出す専用のオブジェクトを作るわけ。
部署管理なら、部署管理データを操作する専用のオブジェクトを設計する。
> 今回の程度の場合、細分化して部署クラスとかを作るんじゃなくて、
いや、部署オブジェクト（部署１つ分）のインスタンス（群）をリクエストに応じて生成するオブジェクトですね。
「こんな部署のリストください」と言ったら「はい、これとこれ」と言ってDBを勝手に検索して結果を渡して
くれるような存在。こういったオブジェクトには、部署データの更新なんかも任せれば良いかも知れない。
こうすれば、メインルーチンではDBへのSQL文をどうすればいいとか考えなくて済むし、
それもオブジェクト指向のメリット。SQL文絡みのエラーが出れば、それは「人事課オブジェクト」の
設計のせいだとすぐ分かる＝バグの原因の特定が容易。
>>251
> PHPでも工夫すればオブジェクト指向開発できるって言っても、そんな不毛な工夫するより、
> その言語に適した開発アプローチを取るべきだと思う。
全然不毛ではないよ。ある程度以上の規模になると開発効率が全く違う。
本当に不毛ならなぜPEARがほとんどOOで書かれているのかと。
Perlのようにただパッケージを拡張しただけみたいな物でも充分使いではあるよ。
問題は機能の多彩さではなく、OOな考え方でプログラミングが可能かどうか。
機能はその補助（そしてあるときはOOな考え方を強制・補正する束縛）に過ぎない。
構造化プログラミングな思考で書かれたモノと正しいOOな思考で書かれたモノでは
開発効率も保守性も全然違う。
0265nobodyさん
2005/06/17(金) 11:33:13ID:???>問題は機能の多彩さではなく、OOな考え方でプログラミングが可能かどうか。
>機能はその補助（そしてあるときはOOな考え方を強制・補正する束縛）に過ぎない。
なかなか的を得てる表現だと思った。
>それだとqueryに変なモノを渡された時に困るので、DBオブジェクトは直接
>使わないようにして、queryを出す専用のオブジェクトを作るわけ。
メソッドの引数にSQL文をとらなければいいだけだと思うが。
作成するDBクラス自体に汎用性を持たせたいなら別だけど。
OOP練習中の>>250にはやや冗長かと。
0267nobodyさん
2005/06/17(金) 11:45:33ID:???リンクぐらい書かないとね
http://jp.php.net/manual/ja/language.oop.newref.php
0269nobodyさん
2005/06/17(金) 13:24:27ID:???>global $globalref;
>$globalref[] = &$this;
>// 内部への参照グローバル配列 $globalref を作成
>global $globalref;
>$globalref[] = &$this;
。。。なんかこれ、日本語がやばくないか？
「グローバルな配列 $globalref の中に参照(&$this)をひとつ作る(入れる)」ってことだよね？
0271nobodyさん
2005/06/17(金) 14:07:56ID:???最初のはインスタンスのコピーを返すが、2番目のは参照を返す。じゃなかったっけか。
$obj = new MyClass();
$obj2 = new MyClass();
$obj->setName("hello");
$obj2->setName("world");
$obj->printName();
実行結果: hello
$obj =& new MyClass();
$obj2 =& new MyClass();
$obj->setName("hello");
$obj2->setName("world");
$obj->printName();
実行結果: world
試してないけどこんな感じでは？
>>261
てきとー訳
> Strict Standards: Assigning the return value of new by reference is deprecated in C:\home\php\test.php on line 5
> 厳密な標準: newの戻り値を参照で割り当てるのは推奨されません。場所 C:\home\php\test.php の 5 行目
>>270
これもやってないけど、PHP4と同じ振る舞いをするんではなかろうか。
0272nobodyさん
2005/06/17(金) 14:27:34ID:???WEBプログラミングっていうのは、ユーザの入力を受け取って、それをDBに入れて、DBから出したものを加工して表示する。
このシーケンシャルな処理の繰り返しに過ぎない。
JavaのStrutsを例にとっても、あれをオブジェクト指向って印象は受けない。
入力データのチェックと画面遷移の仕組みを用意してあるだけだから。だけど、WEBプログラミングにはそれで十分なんだよね。
あれ以上の機能を持たすと、オーバースペックになって使いづらくなるから。
0273nobodyさん
2005/06/17(金) 14:30:50ID:???ほうほう
0274nobodyさん
2005/06/17(金) 14:37:07ID:???それは必要ないから、WEBアプリでは適用しづらいからだと思う。
FLASHとかAjaxみたいなのは別だろうけど、HTTPリクエストドリブンなWEBアプリだと使いどころが見つからない。
0275nobodyさん
2005/06/17(金) 14:45:35ID:???0276nobodyさん
2005/06/17(金) 14:47:54ID:???http://zope.jp/dictionary/SESSION%20object
0277nobodyさん
2005/06/17(金) 14:52:09ID:???けれど、オブジェクト指向開発が必要なケース、大規模開発のときに、これらの機能がないのは厳しい。
あるものとしてコードを書けって言っても、そんな優秀な人ばかりじゃないし、優秀な人でもミスはするし。
それはPerlでuse strictなしで1000行のプログラム書けっていうようなもの。
これを逆にたどって言えば、PHPでオブジェクト指向開発の意義が薄いってことになる。
0278nobodyさん
2005/06/17(金) 14:53:00ID:???レベルが下がってくるとこのスレは盛り上がるんだよなｗ
>>272 >>274
いつの時代までそんなこと言ってるつもりだ？ｗ
0279nobodyさん
2005/06/17(金) 15:00:46ID:???んで、PHPファイルごとにDBオープンするコード書いて使いまわしが効かなくなって
開発ごとにスクラッチから起こしたり、入力、確認、完了、エラーで4枚似たようなスクリプト
用意してデザイン変わったら4枚とも書き直しだったりするんだよね。
確認画面で値チェックして完了画面ではフリーパスなスクリプトもしょっちゅう見るし。
OOを使わずに「なるほど」と思える大規模なWebプログラムって見たことないな。
完全にオブジェクト指向にする必要性は感じないが、メインルーチンをControlに見立てて
ViewとModelを分離するだけでもかなりすっきりするし保守性も上がる。
こういう風に書いた成果物は使いまわしが効きやすいし。
「そういうのはオブジェクト指向とは呼ばない」と言うなら見解の違いだろう。
少なくともWebアプリケーションでもOOでロジックを分離するメリットはある。
俺も完全に再利用可能な汎用オブジェクトを設計するのは、一部の例外（DBアクセスなど）を
除いてWebアプリケーションでは向いてないと思うけどね。PHP用フレームワークやWeb系PEAR
ライブラリの巨大さ、煩雑さを見るまでもなく。
>>277
> それはPerlでuse strictなしで1000行のプログラム書けっていうようなもの。
え？？？うちは.plの新規ファイルを立ち上げると、
#!/usr/bin/perl
use strict;
が自動的に挿入されるようになってますが？それで何十万行も書いてきましたが？
なんか、strictが面倒と思ってる人ってグローバルスコープの変数や関数使いまくりの
ぐちゃぐちゃなコード書いてそうだな……。普通に書いてればstrictでもエラーなど滅多に出ないんだが。
0280nobodyさん
2005/06/17(金) 15:09:39ID:???> #!/usr/bin/perl
> use strict;
> が自動的に挿入されるようになってますが？それで何十万行も書いてきましたが？
> なんか、strictが面倒と思ってる人ってグローバルスコープの変数や関数使いまくりの
> ぐちゃぐちゃなコード書いてそうだな……。普通に書いてればstrictでもエラーなど滅多に出ないんだが。
そうだよ。だけど、use strictなしでも、変数の使い方に注意すれば、同じプログラムは書ける。
とはいっても、それはかなりプログラマーの集中力を要する。
同様に、型無し、インターフェイスなしの言語で大規模開発をするのは、難しいと思う。ってこと。
0281nobodyさん
2005/06/17(金) 15:13:41ID:???0282nobodyさん
2005/06/17(金) 15:22:59ID:???> そうだよ。だけど、use strictなしでも、変数の使い方に注意すれば、同じプログラムは書ける。
> とはいっても、それはかなりプログラマーの集中力を要する。
いやいやいや、スコープ無視してグローバル使いまくりの方が最終的には疲れるでしょ。
保守性下がるし。ウチはuse strictでエラーが出るようなコードは他の人にも認めてないよ。
もちろん使い捨てのものとかは除く。PHPもファイル間でグローバル共有するのが好きな人が多くて困る。
> 同様に、型無し、インターフェイスなしの言語で大規模開発をするのは、難しいと思う。ってこと。
つまり、そもそも難しいのに構造化プログラミングで書いたらもっと大規模開発は難しくなる、ってことでしょー。
>>279
自己レス
> 俺も完全に再利用可能な汎用オブジェクトを設計するのは、
一度、入力→確認→完了のステップを管理するMVCモデルのクラスを設計したことが
あったんだが、それぞれ継承してメインルーチンから呼び出すと最低でも3*2+1=合計7ファイル、
フォームとかDBとか含めると1処理辺り10枚平気で超えるのでバカバカしいと思い止めた。
(まあフレームワークとか使ったモノをトレースするともっと凄い枚数出てくるけど)。
現在、メインルーチン＝Controlの役割＋Model＋View＋テンプレート＋フォーム＋DAOの
6枚のファイル構成が多いかな。
>>281
まあ本物の大規模開発ならPHPなぞ使わないわな。PHPで片付く案件の中での「大規模」
0283nobodyさん
2005/06/17(金) 15:24:39ID:???> >>272
> んで、PHPファイルごとにDBオープンするコード書いて使いまわしが効かなくなって
> 開発ごとにスクラッチから起こしたり、入力、確認、完了、エラーで4枚似たようなスクリプト
> 用意してデザイン変わったら4枚とも書き直しだったりするんだよね。
> 確認画面で値チェックして完了画面ではフリーパスなスクリプトもしょっちゅう見るし。
画面遷移や入力値チェックのフレームワークがあるのはいいと思うよ。
そういうフレームワークを自作するときにオブジェクト指向で作るのはいいと思う。
別にオブジェクト指向開発がまったくいらないって思ってるわけじゃないよ。
> 完全にオブジェクト指向にする必要性は感じないが、メインルーチンをControlに見立てて
> ViewとModelを分離するだけでもかなりすっきりするし保守性も上がる。
> こういう風に書いた成果物は使いまわしが効きやすいし。
> 「そういうのはオブジェクト指向とは呼ばない」と言うなら見解の違いだろう。
> 少なくともWebアプリケーションでもOOでロジックを分離するメリットはある。
Javaサーブレット+JSPとかだと、唯一のコントローラを作って、そこから別のビジネスロジックを呼び出すとか、JSPファイルを呼び出すとかするけど、
あれをそのままPHPに当てはめる必要はないと思う。
アンケートフォームで画面遷移するようなのだと、そういうのが便利かなと思うけど。
こういうのをファサードパターンとか解説してある本もあるけど、そうなの？って思うよ。
別にif文で条件分岐して、requireすればいいだけじゃん。って思う。
画面表示部分を分けたほうがいいのはその通りだけど、分離できないこともある。JSPのカスタムタグとか、あれが本当に便利な仕組みなのかな？って思う。
まあ、何百画面もあるような大規模なサイトなら便利なんだろうけど。
0284279
2005/06/17(金) 15:38:44ID:???> 別にオブジェクト指向開発がまったくいらないって思ってるわけじゃないよ。
んー、であれば大体同意。ガチガチにどれかのデザインパターンに押し込むような
真似はしなくてもいいと思う。
> 分離できないこともある。
だよね。smartyみたいに泥沼化するのは嫌なので、テンプレートからある程度View側に
文字列を取ってこれる仕組みを用意して、あとは実装依存にしてる。
大規模開発ならテンプレートエンジンを使うのもアリだけど、かえって面倒な場合が多い。
> JSPのカスタムタグとか、あれが本当に便利な仕組みなのかな？って思う。
使ったことはないけど、あんま便利そうには見えない。
0285nobodyさん
2005/06/17(金) 21:07:08ID:???0286nobodyさん
2005/06/17(金) 22:47:57ID:???おまいら、同じこと考えてるのに話が噛み合ってないように見えますよ？
>>277
意訳
「use strict なしでもキッチリしたコード書けるけど、
間違えてもエラー返ってこないからミスしやすい。」
で、>>277はstrictが面倒と思ってるわけではなくて、むしろ逆かと。
0288nobodyさん
2005/06/18(土) 00:23:01ID:???PHPでOO語るならPHP4じゃなくてPHP5を前提にしてくれる？
PHP4なんか過去のものなんだけど？
0290nobodyさん
2005/06/18(土) 00:40:52ID:???それ以外PHP5になにかあったっけ?
Apache2のスレッド処理に対応したとか?
0291nobodyさん
2005/06/18(土) 01:18:08ID:???>PHP4でOOを行うほどPHP5に移ったとき有り難味があるとか。
>それ以外PHP5になにかあったっけ?
そのOOの話がこのスレの話題であるべきもののひとつだろ。
スレッド処理etcはスレ違い。
>>289
>客先のサーバが全部PHP5で動くようになったら考えるよ。
こちらでﾄﾞｿﾞ
ttp://pc8.2ch.net/test/read.cgi/php/1118038954/
0292nobodyさん
2005/06/18(土) 01:36:38ID:???>・・・
>実行結果:？world
>試してないけどこんな感じでは？
いいえ。
>これもやってないけど、PHP4と同じ振る舞いをするんではなかろうか。
いいえ。
0294nobodyさん
2005/06/18(土) 15:57:59ID:???奴らは「PHPのOOは中途半端」とかいわれるのを恐れているの？
それともPHP6でOOPLになる予定なの？
0296nobodyさん
2005/06/18(土) 21:42:40ID:???曖昧すぎでわからん。
0298nobodyさん
2005/06/18(土) 23:39:02ID:???俺もOOPLじゃない理由はない気がするけど。
なんでマニュアルにOOPLじゃないと書いてあんだろう？
http://www.php.net/manual/ja/language.oop.object-comparison-php5.php
どこに書いてあったか忘れてたから探すのに手こずった。
日本語版の方ではPHP4のOOPのサブカテゴリだけど英語版の方ではPHP5側に移動されてるからいつリンクが切れるかわからんな。
一応英語版はこっち。
http://www.php.net/manual/en/language.oop5.object-comparison.php
0302nobodyさん
2005/06/19(日) 00:43:26ID:???できるようになればいいのにな。
0304nobodyさん
2005/06/19(日) 01:55:50ID:???0305nobodyさん
2005/06/19(日) 04:03:28ID:kZXyYjBV配列で事足りるけど、OO的に操作できないので
何か気持ち悪い V.S. 面倒の気持ちが戦っているんだけども
0306nobodyさん
2005/06/19(日) 05:47:08ID:???0307nobodyさん
2005/06/19(日) 06:52:44ID:???$obj->method()
の形で要素をいじれないでしょ？
0308nobodyさん
2005/06/19(日) 07:06:01ID:???まあ>>305で言っている通り配列で事足りるわけだし、漏れは作ろうと思ったことないな。
Listクラス作っても計算量を減らせるわけでもなさそうだし。
なんなら配列をメンバにもてばそれまでって気が・・・。
Javaみたいになんでもかんでも継承して使いたい的な考え？
漏れにはよく利点がわからないけど、なんかの役に立つってなら知りたいかも。
解説ｷﾎﾞﾝ。
0309nobodyさん
2005/06/19(日) 07:37:39ID:???0310nobodyさん
2005/06/19(日) 07:52:19ID:???0311nobodyさん
2005/06/19(日) 11:07:45ID:???0312nobodyさん
2005/06/19(日) 11:27:33ID:???よくPHPでｶﾞﾝｶﾞﾙな・・・・・・
ちなみにListってどう実装してんの？
class Node { private $data, $next; }
で$nextに参照いれるとか？
class List { private $array; }
だったりしてｗ
0313nobodyさん
2005/06/19(日) 12:08:25ID:???いや、逆にOO厨がPHPなんて全然OOじゃない！とか
言い出しそうなので先手を打っといたって感じがする
（あるいは既に叩かれたので書き足したとか）。
C++をOOPLじゃないと攻撃するPHPユーザは見たことないが、
PHPやC++をOOPLじゃないと攻撃するOO厨は沢山いるんじゃん？
print "abc";
こういうのもOOじゃないって怒る人いるよね。
"abc"->print();
すべからくこうすべきだと。
0315nobodyさん
2005/06/19(日) 13:28:36ID:9u3ddzIOPOSTのチェックはifの連続以外になんかないですか
0316nobodyさん
2005/06/19(日) 13:34:42ID:???0317nobodyさん
2005/06/19(日) 13:38:10ID:???名前がありませんとか長すぎますみたいなやつ
if(! $name) {...}
else($name > 100){...}
みたいな
0318nobodyさん
2005/06/19(日) 13:48:42ID:???まあ俺だったら空欄系は空欄系で、文字列長さ系は文字列長さ系で、不正文字系は不正文字系でまとめるけど。
どうでもいいけどそのコードテキトー杉だなｗ
0320nobodyさん
2005/06/19(日) 14:15:23ID:???function strLengthCheck ($str, $min, $max) {
if(strlen($data) < $min and strlen($data) > $max) {
return "長さが変だよ";
} else {
return 0;
}
}
こういうことにしても結局同じになるんだよなー
0321nobodyさん
2005/06/19(日) 15:04:48ID:???>>319
つ http://www.planewave.org/translations/quickform/html_quickform.html
ちと重いし使いにくいけどな。
こういうの参考にして自分なりにパッケージ作ってもいいし。
0322nobodyさん
2005/06/19(日) 15:31:14ID:???アドホックな使い方が出来るのがPHPの良さだし、
雑種的なものとして成長してきたから、
「必ずOOPを推奨するものでは決してありません」と言いたいのでは？
敷居の広さをアピールしているように俺は受け取ったが。
0323nobodyさん
2005/06/19(日) 15:41:22ID:???$length_limits = array(
'name' => array(5, 10),
'message' => array(0, 500),
...); // この部分DBやファイルに入れといて取得してもいいし。
foreach ($length_limits as $key => $limits)
{
list($min, $max) = $limits;
$len = strlen($_POST[$key];
if ($len < $min or $len > $max)
// 長さが変だよ
else
// 変じゃないよ
}
っていうかそんなに面倒だと思ったことないけどな。
0324nobodyさん
2005/06/19(日) 15:44:30ID:???0325nobodyさん
2005/06/19(日) 15:51:46ID:???0326nobodyさん
2005/06/19(日) 15:58:40ID:???一理あるな。
PHPはOOPでもいけるけど、使わなくてもいけるってのは大きな利点。
俺的にPHP5のOOはけっこうｲｲと思ってる。
中にはPHPはプリミティブ型がオブジェクトでないとか言う奴いそうだけど、そこまで不便でもないし。
まー型なし言語って意味で仲間のJavaScriptみたいなプリミティブ型の実装もけっこう好きだけど。
ガッチガチのOOしたいならOOPLを選べばいい。
0327nobodyさん
2005/06/19(日) 16:44:14ID:???同意。
>>325
チェックの条件を正規化してないから。でしょ多分。
んでも俺はクラス化してるけど、パスワードチェックの部分なんかはかなりif文並んでるよ。
※うちで必ずやる客が入力したパスワード検証
・英文字＋αになっているか（英文字だけ、制御文字、バイナリ、日本語コードなどはNG）
・0123とかabcdとかasdfgとかqwertyとかが含まれていないか
・同じ文字が4つ以上連続していないか
・ユーザー名と同じでないか
・ユーザー名の逆順と同じでないか
・メールアドレスの左側と同じでないか
・メールアドレスの左側の逆順と（略
： めんどくさいのでやめ
て感じで推測されやすそうなのは全部弾き飛ばしてる。大きいシステムになると
ローマ字＋英語のdic使って単語の組は弾いたりするよ。
0328nobodyさん
2005/06/19(日) 17:13:00ID:???そこにあげた項目ほとんどが結局はpreg_matchの類だろ。
だったらパターンだけ配列にいれてforeachで回せばifなんか激減だろ。
あ、いや、>>327に言ってるわけじゃなくて。>>324がifじゃ嫌とかいう話だったから。
>>327はifが並んでても気にしてないみたいだから好きなだけ並べてください。
0329nobodyさん
2005/06/19(日) 19:13:02ID:???文字数のmax・minチェックは？
必須チェックもあるだろ？
日付の妥当性チェックなんてのもある。
あんたが言うほど単純なものじゃないんだよ。
0330nobodyさん
2005/06/19(日) 19:20:24ID:???0332328
2005/06/20(月) 03:52:16ID:???パスワードのチェックを一生懸命頑張ってるのはわかったよ。
そこまでやると利用者にとってはﾑｶつくだけの機能だけどなｗ
ちなみに俺はifの話をしてるだけなので。
ifは３回で済むやんその部分・・・
と言ってみる。
ちなみにもう一回言うけど、あんたがifを並べて書く分には文句ない。
>>315から始まったifダラダラが嫌な方々に対しての話だから。
それとも>>329=>>327=>>324=>>320=>>319=>>317=>>315だった？
それだったら必死こくのもうなずけるｗ
0333nobodyさん
2005/06/20(月) 07:26:24ID:???Singletonやたら多くね？
RequestやらSessionやらControllerやら、
基幹部品ほとんどSingletonになるやん。
0334nobodyさん
2005/06/20(月) 10:13:11ID:???まあ WebProgramming ってのはそういうものな気がする
漏れが1クラスで2つ以上のインスタンスを作るのって composite 系ぐらい
0336332
2005/06/20(月) 17:13:53ID:???あ、そいつは失敬・・・orz
なんか俺が書いた332の文章読み返してみたら、そうとうｲﾊﾟｲﾊﾟｲだな。
反省。
>>333
たしかに制御部分なんかはシングルトンばっかだけどコンテンツと直接関連するとこはけっこうインスタンスつくるな。
インスタンスつくればつくるほど（ＯＯじゃない場合に比べて）重くなっていくのがｳｻﾞｲけど。
ＰＨＰ５だとその辺いかがなもんだろ？
0337333
2005/06/20(月) 19:57:28ID:???Singletonは実装がちょっとだけ面倒だな。
継承で実現できないから毎回同じルーチンをコピペしなきゃならないし。
>>336
4のなんちゃってOOよりは速くなってるはずだよ。
俺もインスタンスのリストも作ってるけど
DBから読んでいっぺんにオブジェクト全部作るより、
一つずつインスタンス作っては表示した方が、メモリ消費量は少ないよなぁとか思いだしたら
一層Singleton傾向が強くなっていくんだよな。
0338nobodyさん
2005/06/20(月) 22:01:02ID:???結構書かれててビビる。
でも便利すぎるから使いまくりな俺。
大丈夫、ResultやらControllerやらConfig何個も作るなんて
ｱﾘｴﾅｲｱﾘｴﾅｲ……
ほとんどデータ格納系となんかの基底クラスだけだ、シングルトン使ってないの。
ヤバいか。ヤバいかも。
0339nobodyさん
2005/06/20(月) 23:34:21ID:???Singletonは便利な反面、保守性を低くしがちでもあるから諸刃の剣だよな。
継承できないのもｲﾀｲ。アクセス制限もｼﾝﾄﾞｲ。
でも便利・・・。
誰かもっとﾋﾞｭｰﾃｨﾎｰなデザパタ考案汁！
とりあえず使いすぎない程度にほどほどでいった方がいいと思うけど。
>>337
基本的には一つずつインスタンス作って表示でいきたいんだけどね〜。
ちょっと特殊なソートをやるときってどうしてもまとめて読み込むしかないんだよな。
ソートが必要だと一般にＤＢにやらせてもどうせ同じだけメモリ食ってるだろうし。
（詳しく知らんけどたぶん）
っていうかＰＨＰにソートをやらせると速度激減ｗ
0340nobodyさん
2005/06/20(月) 23:58:34ID:???その逆も楽。
あっすまん。PHPだと無理だ。
0341nobodyさん
2005/06/21(火) 01:22:49ID:???0342nobodyさん
2005/06/21(火) 03:18:21ID:???■ このスレッドは過去ログ倉庫に格納されています