ウェブプログラミングで使えるデザインパターン

ｹﾞｯﾁｭｰﾎﾟﾝ

結構良ｽﾚっぽいｽﾚﾀｲなのに、>>1がｸｿで萎え

こんなスレはシングルトンであって欲しいものだ。

とにかくリクエストとレスポンスが一組になる
１パターンリクエストに対し数パターンのレスポンスがあって、他パターンのリクエストと共通だったりする

>>4
で？

サーブレットは知らんがCGI、PHPあたりだとだいたい

フォームデータ処理
if
　エラー表示１
else if
　エラー表示２
・・・
else if
　処理１
　フェーズ１表示
else if
　処理２
　フェーズ２表示
・・・・
って感じになるな

>>6
えと、>>1はGoF辺りのデザパタを聞きたいんではないかと。

後、それダサい。

>>7
だって>>6=>>1だもん
じゃあｶｺｲｲやつｶﾓﾝ

ここでいうデザインパターンってなんですか？

GoFに限定しないオブジェクト指向にも限定しない
寧ろウェブプログラミングのためのパターン

GOFのどれがWEBプログラミングに使われるんですか？

PHP関連でそういった事を解説してるサイトなかった？>WEBPrograming/DesignPattern
Stateパターンでログイン・ユーザの認証状態を管理する。etc

コーディングに特化しない話題でもいいなら、
WEB関連&&デザインパターンという事で、こんなサイトも。
http://www.designpattern.lu.unisi.ch/index.htm

まずはPerl5やPHPにGoFを翻訳することからはじめるか
Perl5やPHPって継承やインターフェース使えたっけ？

http://www.pat.hi-ho.ne.jp/dimension/sample/sample_class_list.shtml
のサイトでもPHPでデザパタしてる。
プログラム板にも初心者向けのデザパタスレがあるから、
デザインパターンって何？って人はそちらも合わせて見るといいかと。

>>13
GOFの実装例なら、すでに幾つかありますね。
http://www.perldesignpatterns.com/

Perl5 や PHP4 にはインターフェースのための構文は用意されていないので、
(標準では)Javaみたいにインターフェースで定義したメソッドの実装を強制する事は出来ません。
多くのサンプルでは、インターフェース代わりに空メソッドを定義しているだけか、
実行時にメソッドが実装されていなければ終了する。と、いったものが殆んどの様です。

インターフェースを継承したクラスがそのメソッドを実装しているか確認したいのであれば。
perlについては、CPANにコンパイル時にインターフェースをチェックするモジュールがあります。
PHPでは、PHP5からインターフェースが導入されています。

ごめん、インターフェースって何？継承とは違うのかい？

インターフェースは知らんけど継承はわかるのか？
なんじゃそりゃ

ウェブプログラミングじゃあんまGoF通用しないんじゃね？
Perl PHP Rubyじゃインターフェース無いし、GUIもHTML吐いて作るわけだし、
インスタンスを次のセッションで使うのもしんどいじゃん

>>18
＞Perl PHP Rubyじゃインターフェース無いし
プロトタイプベースだからいらんでしょ。アホか。

＞GUIもHTML吐いて作るわけだし、
むしろその辺のGUI部品より融通が利くわけだが。


後、J2EEとかASP.NETはWebプログラミングに入らないんですか？
完全無料主義者のあなたの中では。

オブジェクト指向が必要なほど大規模になることもなく
やっぱり>>6みたいなものになっちまうのか

>>6を汎用的に書ければいいんだけど

>>18
オブジェクトの永続化について調べてみるといいかも。
PHPなんかでは、普通にセッションにオブジェクトを格納出来るよ。

>>20
一連の処理をひとつのアプリケーションとし、
各処理をそのアプリケーションの状態とみなすと、
Stateパターンを適応できますね。perlのCGI::Application みたいに。

勿論、非オブジェクト指向でも同様の処理は可能です。
ハッシュ等にキーと処理へのポインタを登録し、
与えられたキーの処理を呼び出すといった方法で、冗長な分岐から解放されます。


ところで、ウェブプログラミングで*使える*(eq 有用な？)デザインパターンって、
例えばどんなの？

Webプログラミングの場合、GUIより、モデルやコントローラ周りでの
プログラミングでデザインパターンを多用するケースが多い気が。

結城 浩著書の本は役立ってます。

>>19がなんでそんな必死になるのかわからんし
全然反論になってない

ごめん、クラスの組み合わせがデザインパターン？
つかデザインパターンを易しく説明きぼんぬ。まじで。

GOFならぐぐればいくらでもでてくる

Web Service なシステムを作る上でのデザインパターンなら考えられるかも
ConcreteStrategy を一個の CGI として実装して… うーいまいちメリットないな

フォームデータ処理
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とあんま変わらんな

MVCさいこー。
いや、本気で。

テンプレート使えばモデルとビューは分離できるな

>>25
オブジェクト指向にクラスが必須ではないのと同じくらい、
デザインパターンにオブジェクト指向が必須という訳ではないと思う。（私見）
オブジェクト指向以外でも応用することが出来ます。

>>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);
}
}