ウェブプログラミングで使えるデザインパターン
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/11/22 06:56ID:Lh+gL3bz0003nobodyさん
03/11/22 22:25ID:???0004nobodyさん
03/11/22 22:44ID:LH4aw5t2１パターンリクエストに対し数パターンのレスポンスがあって、他パターンのリクエストと共通だったりする
0006nobodyさん
03/11/23 19:42ID:???フォームデータ処理
if
エラー表示１
else if
エラー表示２
・・・
else if
処理１
フェーズ１表示
else if
処理２
フェーズ２表示
・・・・
って感じになるな
0009nobodyさん
03/11/24 15:47ID:???0010nobodyさん
03/11/24 23:53ID:6o1aVvpy寧ろウェブプログラミングのためのパターン
0011nobodyさん
03/11/25 17:04ID:???0012nobodyさん
03/11/26 12:58ID:e6YvtpHrStateパターンでログイン・ユーザの認証状態を管理する。etc
コーディングに特化しない話題でもいいなら、
WEB関連&&デザインパターンという事で、こんなサイトも。
http://www.designpattern.lu.unisi.ch/index.htm
0013nobodyさん
03/11/26 13:08ID:???Perl5やPHPって継承やインターフェース使えたっけ？
0014nobodyさん
03/11/26 16:20ID:???のサイトでもPHPでデザパタしてる。
プログラム板にも初心者向けのデザパタスレがあるから、
デザインパターンって何？って人はそちらも合わせて見るといいかと。
0015nobodyさん
03/11/27 00:07ID:0zBWj9/pGOFの実装例なら、すでに幾つかありますね。
http://www.perldesignpatterns.com/
Perl5 や PHP4 にはインターフェースのための構文は用意されていないので、
(標準では)Javaみたいにインターフェースで定義したメソッドの実装を強制する事は出来ません。
多くのサンプルでは、インターフェース代わりに空メソッドを定義しているだけか、
実行時にメソッドが実装されていなければ終了する。と、いったものが殆んどの様です。
インターフェースを継承したクラスがそのメソッドを実装しているか確認したいのであれば。
perlについては、CPANにコンパイル時にインターフェースをチェックするモジュールがあります。
PHPでは、PHP5からインターフェースが導入されています。
0016nobodyさん
03/11/27 00:41ID:???0017nobodyさん
03/11/27 02:07ID:???なんじゃそりゃ
0018nobodyさん
03/11/27 02:15ID:???Perl PHP Rubyじゃインターフェース無いし、GUIもHTML吐いて作るわけだし、
インスタンスを次のセッションで使うのもしんどいじゃん
0019nobodyさん
03/11/27 06:30ID:???＞Perl PHP Rubyじゃインターフェース無いし
プロトタイプベースだからいらんでしょ。アホか。
＞GUIもHTML吐いて作るわけだし、
むしろその辺のGUI部品より融通が利くわけだが。
後、J2EEとかASP.NETはWebプログラミングに入らないんですか？
完全無料主義者のあなたの中では。
0021nobodyさん
03/11/27 07:31ID:0zBWj9/pオブジェクトの永続化について調べてみるといいかも。
PHPなんかでは、普通にセッションにオブジェクトを格納出来るよ。
0022nobodyさん
03/11/27 08:17ID:0zBWj9/p一連の処理をひとつのアプリケーションとし、
各処理をそのアプリケーションの状態とみなすと、
Stateパターンを適応できますね。perlのCGI::Application みたいに。
勿論、非オブジェクト指向でも同様の処理は可能です。
ハッシュ等にキーと処理へのポインタを登録し、
与えられたキーの処理を呼び出すといった方法で、冗長な分岐から解放されます。
ところで、ウェブプログラミングで*使える*(eq 有用な？)デザインパターンって、
例えばどんなの？
0023nobodyさん
03/11/27 08:46ID:8RwaY1jwプログラミングでデザインパターンを多用するケースが多い気が。
結城 浩著書の本は役立ってます。
0024nobodyさん
03/11/27 11:23ID:lzQjXivq全然反論になってない
0025nobodyさん
03/11/27 12:31ID:???つかデザインパターンを易しく説明きぼんぬ。まじで。
0026nobodyさん
03/11/27 13:01ID:???0027nobodyさん
03/11/27 13:58ID:???ConcreteStrategy を一個の CGI として実装して… うーいまいちメリットないな
0028nobodyさん
03/11/27 14:15ID:???if
obj=new Hoge(query);
else if
obj=new Piyo(query);
else if
obj=new Foo(query);
else if
obj=new Bar(query);
・・・・
obj.proc
>>6とあんま変わらんな
0029nobodyさん
03/11/27 16:50ID:???いや、本気で。
0030nobodyさん
03/11/27 17:03ID:???0031nobodyさん
03/11/27 22:02ID:0zBWj9/pオブジェクト指向にクラスが必須ではないのと同じくらい、
デザインパターンにオブジェクト指向が必須という訳ではないと思う。（私見）
オブジェクト指向以外でも応用することが出来ます。
>>28
>>22 の方法、伝わらなかったかな。サンプルこんな感じです。
use CGI;
my $query = new CGI;
my $app = new App(
func1 => \$func1,
func2 => \&func2,
func3 => \&func3
);
$app->exec($query->param('mode'), $query);
sub func1 { my ($query) = @_; print "func1\n"; }
sub func2 { my ($query) = @_; print "func2\n"; }
sub func3 { my ($query) = @_; print "func3\n"; }
package App;
sub new {
my ($class, %menu) = @_;
bless({menu => \%menu}, $class);
}
sub exec {
my ($self, $key, @args) = @_;
if (ref $self->{menu}->{$ket} eq 'CODE') {
&{$self->{menu}->{$key}}(@args);
}
}
0032nobodyさん
03/11/27 22:15ID:0zBWj9/pアプリケーションサーバや、フレームワーク内でなら使われてる例は多いよね。GOFに限らず。
うーん、OOP/GOF な話題がメインなのかな、ここ？
WEBパターンとかの話題はスレor板違い？
http://www.c2.com/cgi/wiki?WebsitePatterns
0033nobodyさん
03/11/27 22:29ID:???非オブジェクト指向言語でオブジェクト指向ごっこしたら大体は破綻するけどね。
言語もパターンも使いよう。
あんたの実力はソースコードレビューではなく客先試験で発揮して下さいよって感じになりかねない。
0038nobodyさん
03/11/28 07:55ID:???デザパの勉強なるよ
0040nobodyさん
03/11/28 10:57ID:???0041nobodyさん
03/11/28 12:33ID:???0042nobodyさん
03/11/28 17:57ID:9mFpNgVwhttp://www.hyuki.com/dp/dpfaq.html DesignPatterns FAQ日本語訳
パターンとは、あるコンテキスト（状況・背景）上の問題に対する一つの解決策。
繰返し発生するコンテキストは、フォームデータ処理などで発生する if else の条件分岐 like >6 >28
問題は、条件分岐の文にbugが混入しやすい事
解決策の一つは、>22 冗長な分岐を排除する。
これなら、オブジェクト指向でなくとも、ハッシュの様なデータ構造さえ使えれば適用できるでしょう？
これだけでは不十分で、これ以外にもこのパターンはどう言った時に適用すると良いとか、
適用した場合にどういった状況になるか、他に考慮するべき事もパターンに記述されます。
詳しくはパターン・ランゲージについて調べてみて。
"パターン"が理解出来たら、デザインパターンはすぐ理解出来ると思う。でも
単純に、すべてのクラスの組合せがデザインパターンと呼ばれるわけではない。（FAQにもそう書かれている）
"パターン"として有益な情報に成り得るのは、特定の条件の元の問題に対して。
組合せを指して"パターン"と呼んでいるのではないので。
デザインパターンの考え方は、オブジェクト指向をサポートしていない言語にとっても有用だと思う。
別に非OOP言語でのOOを推奨しているわけではないよ。>18 >19 >24 に対するフォローのつもり。>32
0043nobodyさん
03/11/28 19:07ID:???0044nobodyさん
03/11/29 13:48ID:???phpにおいて、というならまぁそうなのかもな。
リファクタリングされてないようなのがいっぱいあるけど。
なんか重いし、無駄が多いし、好きになれない
0046nobodyさん
03/11/29 22:56ID:???実運用で使うようなモジュールはだいたい限られてるし、
そういうモジュールはよくメンテされてて
実用的で使えるのは結構あると思うけど。
ライブラリからリファクタリングしないと
重かったりして困るようなパフォーマンス命な
仕事なんてやったこと無いので
そういう時に使うべきかどうかというのは
判断が必要かもしれないけど
0047nobodyさん
03/11/29 23:21ID:???だな。
なんらかのライブラリ群や、フレームワークを使ったとき、
ハード資源消費量は、無駄な機能の占める割合が高かったりするもんな。
それでも、漏れらは使うのさ。
信頼性のあるライブラリだし、開発コストが下がるから。
客から動作がにぶくなってきたって、言われたら、
「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
宇摩ー。
0049nobodyさん
03/11/30 00:32ID:Fs/0s5IP実際modeで分離なんて簡単にはいかない
005046
03/11/30 00:35ID:???してないっす
>>49
Webで現実的な問題はやっぱり時間
金銭的なコストというよりも時間のコストが
惜しいケースが多い
（もちろんそれが金銭的なコストにも
繋がってくるのはそうなのだろうけど）
PHPは大規模なwebアプリにも通用するとは思うけど
確かにフレームワーク的なものは発展中
だからこそPEARがその役割を担っていくと考えてる
PHP5ではよりPEARの役目は大きくなると思う
■ このスレッドは過去ログ倉庫に格納されています