ウェブプログラミングで使えるデザインパターン (170ﾚｽ)
上下前次1-新
1(3): 03/11/22 06:56 ID:Lh+gL3bz(1) AAS
ｹﾞｯﾁｭｰﾎﾟﾝ
2(1): 03/11/22 11:16 ID:??? AAS
結構良ｽﾚっぽいｽﾚﾀｲなのに、>>1がｸｿで萎え
3: 03/11/22 22:25 ID:??? AAS
こんなスレはシングルトンであって欲しいものだ。
4(1): 03/11/22 22:44 ID:LH4aw5t2(1) AAS
とにかくリクエストとレスポンスが一組になる
１パターンリクエストに対し数パターンのレスポンスがあって、他パターンのリクエストと共通だったりする
5: 03/11/22 23:15 ID:??? AAS
>>4
で？
6(12): 03/11/23 19:42 ID:??? AAS
サーブレットは知らんがCGI、PHPあたりだとだいたい
フォームデータ処理
if
エラー表示１
else if
エラー表示２
・・・
else if
処理１
フェーズ１表示
else if
処理２
フェーズ２表示
・・・・
って感じになるな
7(1): 03/11/23 21:40 ID:??? AAS
>>6
えと、>>1はGoF辺りのデザパタを聞きたいんではないかと。
後、それダサい。
8: 03/11/23 22:36 ID:??? AAS
>>7
だって>>6=>>1だもん
じゃあｶｺｲｲやつｶﾓﾝ
9: 03/11/24 15:47 ID:??? AAS
ここでいうデザインパターンってなんですか？
10: 03/11/24 23:53 ID:6o1aVvpy(1) AAS
GoFに限定しないオブジェクト指向にも限定しない
寧ろウェブプログラミングのためのパターン
11: 03/11/25 17:04 ID:??? AAS
GOFのどれがWEBプログラミングに使われるんですか？
12: 03/11/26 12:58 ID:e6YvtpHr(1) AAS
PHP関連でそういった事を解説してるサイトなかった？>WEBPrograming/DesignPattern
Stateパターンでログイン・ユーザの認証状態を管理する。etc
コーディングに特化しない話題でもいいなら、
WEB関連&&デザインパターンという事で、こんなサイトも。
外部ﾘﾝｸ[htm]:www.designpattern.lu.unisi.ch
13(1): 03/11/26 13:08 ID:??? AAS
まずはPerl5やPHPにGoFを翻訳することからはじめるか
Perl5やPHPって継承やインターフェース使えたっけ？
14: 03/11/26 16:20 ID:??? AAS
外部ﾘﾝｸ:www.pat.hi-ho.ne.jp
のサイトでもPHPでデザパタしてる。
プログラム板にも初心者向けのデザパタスレがあるから、
デザインパターンって何？って人はそちらも合わせて見るといいかと。
15: 03/11/27 00:07 ID:0zBWj9/p(1/5) AAS
>>13
GOFの実装例なら、すでに幾つかありますね。
外部ﾘﾝｸ:www.perldesignpatterns.com
Perl5 や PHP4 にはインターフェースのための構文は用意されていないので、
(標準では)Javaみたいにインターフェースで定義したメソッドの実装を強制する事は出来ません。
多くのサンプルでは、インターフェース代わりに空メソッドを定義しているだけか、
実行時にメソッドが実装されていなければ終了する。と、いったものが殆んどの様です。
インターフェースを継承したクラスがそのメソッドを実装しているか確認したいのであれば。
perlについては、CPANにコンパイル時にインターフェースをチェックするモジュールがあります。
PHPでは、PHP5からインターフェースが導入されています。
16: 03/11/27 00:41 ID:??? AAS
ごめん、インターフェースって何？継承とは違うのかい？
17: 03/11/27 02:07 ID:??? AAS
インターフェースは知らんけど継承はわかるのか？
なんじゃそりゃ
18(3): 03/11/27 02:15 ID:??? AAS
ウェブプログラミングじゃあんまGoF通用しないんじゃね？
Perl PHP Rubyじゃインターフェース無いし、GUIもHTML吐いて作るわけだし、
インスタンスを次のセッションで使うのもしんどいじゃん
19(2): 03/11/27 06:30 ID:??? AAS
>>18
＞Perl PHP Rubyじゃインターフェース無いし
プロトタイプベースだからいらんでしょ。アホか。
＞GUIもHTML吐いて作るわけだし、
むしろその辺のGUI部品より融通が利くわけだが。
後、J2EEとかASP.NETはWebプログラミングに入らないんですか？
完全無料主義者のあなたの中では。
20(1): 03/11/27 07:30 ID:??? AAS
オブジェクト指向が必要なほど大規模になることもなく
やっぱり>>6みたいなものになっちまうのか
>>6を汎用的に書ければいいんだけど
21: 03/11/27 07:31 ID:0zBWj9/p(2/5) AAS
>>18
オブジェクトの永続化について調べてみるといいかも。
PHPなんかでは、普通にセッションにオブジェクトを格納出来るよ。
22(2): 03/11/27 08:17 ID:0zBWj9/p(3/5) AAS
>>20
一連の処理をひとつのアプリケーションとし、
各処理をそのアプリケーションの状態とみなすと、
Stateパターンを適応できますね。perlのCGI::Application みたいに。
勿論、非オブジェクト指向でも同様の処理は可能です。
ハッシュ等にキーと処理へのポインタを登録し、
与えられたキーの処理を呼び出すといった方法で、冗長な分岐から解放されます。
ところで、ウェブプログラミングで*使える*(eq 有用な？)デザインパターンって、
例えばどんなの？
23: 03/11/27 08:46 ID:8RwaY1jw(1) AAS
Webプログラミングの場合、GUIより、モデルやコントローラ周りでの
プログラミングでデザインパターンを多用するケースが多い気が。
結城 浩著書の本は役立ってます。
24(1): 03/11/27 11:23 ID:lzQjXivq(1) AAS
>>19がなんでそんな必死になるのかわからんし
全然反論になってない
25(2): 03/11/27 12:31 ID:??? AAS
ごめん、クラスの組み合わせがデザインパターン？
つかデザインパターンを易しく説明きぼんぬ。まじで。
26: 03/11/27 13:01 ID:??? AAS
GOFならぐぐればいくらでもでてくる
27: 03/11/27 13:58 ID:??? AAS
Web Service なシステムを作る上でのデザインパターンなら考えられるかも
ConcreteStrategy を一個の CGI として実装して… うーいまいちメリットないな
28(2): 03/11/27 14:15 ID:??? AAS
フォームデータ処理
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とあんま変わらんな
29: 03/11/27 16:50 ID:??? AAS
MVCさいこー。
いや、本気で。
30: 03/11/27 17:03 ID:??? AAS
テンプレート使えばモデルとビューは分離できるな
31(3): 03/11/27 22:02 ID:0zBWj9/p(4/5) AAS
>>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);
}
}
32(1): 03/11/27 22:15 ID:0zBWj9/p(5/5) AAS
>> 23
アプリケーションサーバや、フレームワーク内でなら使われてる例は多いよね。GOFに限らず。
うーん、OOP/GOF な話題がメインなのかな、ここ？
WEBパターンとかの話題はスレor板違い？
外部ﾘﾝｸ:www.c2.com
33: 03/11/27 22:29 ID:??? AAS
>>31
非オブジェクト指向言語でオブジェクト指向ごっこしたら大体は破綻するけどね。
言語もパターンも使いよう。
あんたの実力はソースコードレビューではなく客先試験で発揮して下さいよって感じになりかねない。
34(3): 03/11/27 23:54 ID:??? AAS
25です。
>>31
ますます分からなくなりました。
これって特殊な例じゃない？
35(1): 03/11/28 00:49 ID:??? AAS
>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め
36(1): 03/11/28 02:36 ID:??? AAS
>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め だってよ。(w
37(1): 03/11/28 06:43 ID:??? AAS
>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め だってよ。(w だってよ。(w
38(2): 03/11/28 07:55 ID:??? AAS
PEARのソースコードは
デザパの勉強なるよ
39: 03/11/28 09:25 ID:??? AAS
>>35-37みたいなのはプロトタイプパターンなのかな
40: 03/11/28 10:57 ID:??? AAS
いまだに（ｗとか使う奴いるんだな・・・
41: 03/11/28 12:33 ID:??? AAS
（ｗ
42: 03/11/28 17:57 ID:9mFpNgVw(1) AAS
ごめん、混乱させるような事言っちゃたかな。>25
外部ﾘﾝｸ[html]:www.hyuki.com DesignPatterns FAQ日本語訳
パターンとは、あるコンテキスト（状況・背景）上の問題に対する一つの解決策。
繰返し発生するコンテキストは、フォームデータ処理などで発生する if else の条件分岐 like >6 >28
問題は、条件分岐の文にbugが混入しやすい事
解決策の一つは、>22 冗長な分岐を排除する。
これなら、オブジェクト指向でなくとも、ハッシュの様なデータ構造さえ使えれば適用できるでしょう？
これだけでは不十分で、これ以外にもこのパターンはどう言った時に適用すると良いとか、
適用した場合にどういった状況になるか、他に考慮するべき事もパターンに記述されます。
詳しくはパターン・ランゲージについて調べてみて。
"パターン"が理解出来たら、デザインパターンはすぐ理解出来ると思う。でも
単純に、すべてのクラスの組合せがデザインパターンと呼ばれるわけではない。（FAQにもそう書かれている）
"パターン"として有益な情報に成り得るのは、特定の条件の元の問題に対して。
組合せを指して"パターン"と呼んでいるのではないので。
デザインパターンの考え方は、オブジェクト指向をサポートしていない言語にとっても有用だと思う。
別に非OOP言語でのOOを推奨しているわけではないよ。>18 >19 >24 に対するフォローのつもり。>32
43: 03/11/28 19:07 ID:??? AAS
ｺｿｰﾘとデザインパターンって何と聞いていいですか
44(3): 03/11/29 13:48 ID:??? AAS
>>38
phpにおいて、というならまぁそうなのかもな。
リファクタリングされてないようなのがいっぱいあるけど。
なんか重いし、無駄が多いし、好きになれない
45: 03/11/29 21:36 ID:??? AAS
>>44
＞リファクタリングされてないようなのがいっぱいあるけど。
は再利用の際の技であり成果物にわざわざ適用しても仕方ないのでは？
46(4): 03/11/29 22:56 ID:??? AAS
>>44
実運用で使うようなモジュールはだいたい限られてるし、
そういうモジュールはよくメンテされてて
実用的で使えるのは結構あると思うけど。
ライブラリからリファクタリングしないと
重かったりして困るようなパフォーマンス命な
仕事なんてやったこと無いので
そういう時に使うべきかどうかというのは
判断が必要かもしれないけど
47(3): 03/11/29 23:21 ID:??? AAS
>>46
だな。
なんらかのライブラリ群や、フレームワークを使ったとき、
ハード資源消費量は、無駄な機能の占める割合が高かったりするもんな。
それでも、漏れらは使うのさ。
信頼性のあるライブラリだし、開発コストが下がるから。
客から動作がにぶくなってきたって、言われたら、
「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
宇摩ー。
48(1): 03/11/29 23:53 ID:??? AAS
>>47
自作自演。
49(3): 03/11/30 00:32 ID:Fs/0s5IP(1) AAS
>>31よりもっと使えるやつｶﾓﾝ
実際modeで分離なんて簡単にはいかない
50(2): 46 03/11/30 00:35 ID:??? AAS
>>48
してないっす
>>49
Webで現実的な問題はやっぱり時間
金銭的なコストというよりも時間のコストが
惜しいケースが多い
（もちろんそれが金銭的なコストにも
繋がってくるのはそうなのだろうけど）
PHPは大規模なwebアプリにも通用するとは思うけど
確かにフレームワーク的なものは発展中
だからこそPEARがその役割を担っていくと考えてる
PHP5ではよりPEARの役目は大きくなると思う
51: 03/11/30 00:43 ID:??? AAS
>>50
PHPで大規模システムって無謀だと思う。
52(1): 03/11/30 00:57 ID:??? AAS
>>49
commandパターンで実装
>>50
モノにもよるんじゃない
パフォーマンスも求められるものはキツいかもしれないが
ただ単に規模だけが大きいんなら
PHPでも十分メンテナンスしやすい
再利用性そこそこのもんはちゃんと作れると思う
53(1): 03/11/30 01:17 ID:??? AAS
>>52
commandパターンがどう使えるのかぜんぜんわかんね
54: 03/11/30 01:33 ID:??? AAS
>>46
リファクタリングの目的はパフォーマンスを多少犠牲にしても
メンテしやすいコードを作ることだよ。
55(1): 03/11/30 01:49 ID:ENFs/Hl7(1/2) AAS
>>53
じゃあ使わんでいいよ、それだけのもんだ
なんで使えるのかなんで使うと得するのか
調べるコストをかけれないなら
最初から使わないのも選択のひとつ
56(1): 03/11/30 01:55 ID:??? AAS
>>55
どーせ言ってみただけなんだろぅ？
57: 03/11/30 02:35 ID:ENFs/Hl7(2/2) AAS
>>56
ああもちろんだ
俺も別に完全になんか理解してるわけない
つーか何しようとしてるか知らんが
その>>49のmode毎にたいそうな処理が
あるならともかくどうせおまえらの事だから
書き込みか確認かとかそんなだろ
なら>>6で別にいいよ
command毎にクラス作って別々の実装のコード書いて
呼び出しが $com->exec(〜) に一見なったところで
>>6がダサいからと単純に割り切るような奴が
中身実装しても良くなるとは思えん
58: 03/11/30 03:11 ID:??? AAS
＞>>6がダサいからと単純に割り切るような奴が中身実装しても良くなるとは思えん
この部分には全く根拠がないし、見当外れだな
59(1): 03/11/30 09:48 ID:??? AAS
>>6
なが〜い関数無しのスクリプトが見えます・・・。
60(3): 03/11/30 10:01 ID:??? AAS
最近WebProg飽きたからやってないけど、昔はこんな感じに組んでたよ。
勝手にSDM-VCモデルとか呼んでたけど。
後から調べたら似たような思想の設計法とかやたらとあってちょっと欝。
S:ストレージ
ファイルとかDBとかを同じメソッドでアクセスできるようにするためのラッパクラス。
三層スキーマの内部スキーマ相当でODBCとかと似たような概念。
ここをモジュール化することで次回から使い回しが可能。
D:データ
ストレージに保存するエンティティ（データ）クラス。
同概念スキーマ相当。JDBC的な考え方。
Sを差し替えるだけで様々な媒体に永続化が可能なため移植が楽に。
M:モデル
言うまでもなく、MVCのM。
ビューに依存しないロジックを提供する。
VC:ビュー&コントローラ
リストボックスとか汎用的な部品だとVとCの分離には激しく意味があると思うが
オーダ特化のVはむしろCと一緒に管理した方が便利という判断でいっしょこたんに。
マンマシンインターフェースを担当する。
61(1): 03/11/30 12:35 ID:??? AAS
>>60 おれもそういう経験あるよ。
有名なモデリングパターンや、デザインパターンを知らかったとき、
もっと効率良く開発したいと心掛けながら、設計していたら、
結局有名なパターンと同じ方法で設計してた。
62: 03/11/30 16:29 ID:??? AAS
>>59
（ ´,_ゝ｀）ﾌﾟｯ
63(1): 03/12/01 02:53 ID:i/vnv4B8(1) AAS
>61
質問いいかな？
MVCとかってパターンランゲージの用語で言う「パターン」に含まれるの？
モデリング・パターンのパターンとか？MVCにもパターンの様なもの
（どういった時にMVCで設計するといい。とか）の記述がある？
自分のデザインパターンに対する認識が他の人とは違ってるよーな気がしてきた。
「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。
64: 03/12/01 06:30 ID:??? AAS
>>63
>>6をパターンとかほざいてるんだからなんでもありっしょ。
65(1): 03/12/01 10:49 ID:??? AAS
>>46-47
いや、>>38でデザパの勉強になるといわれての>>44では？
俺も好きになれない。
よく使いたいと思うものに無駄が多いように見えるから。AuthしかりDBしかり。
sql作るのは Builder & Directorでやって欲しいし、
CREATE 〜なんて AdaptorやDecoratorでいい。
メソッドの中にベタ書きだし、クエリ発行関数はあちこちに散らばってるし。
詳しいわけじゃないけど、これがデザインパターンといわれるとなんか抵抗あるわけですよ。
それでもPEARスレはのぞいちゃうんだけどね。
66: 03/12/01 11:09 ID:??? AAS
無駄が多いんだけならいいんだよ。その分汎用性が高くなってるわけだし。
でもダサいコードが多いじゃん。あれなら Perl で CPAN の方が(ﾟДﾟ)ｳﾏｰ
67(1): 03/12/01 13:06 ID:??? AAS
＞「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
＞等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。
それは、多くの経験の集約から「このパターンはこのケースに使える」というのが出てくるのであって、
今は「こういうパターンがあるんじゃね？」って段階だろ。このスレ的には
68: 03/12/01 19:00 ID:??? AAS
>>60
いわゆるDAOとValueObjectですね。
Javaだとそのあたりを担ってくれるフレームワークも多いけど、
PHPなんかだとこれからの分野なのかな。
69(1): 03/12/01 19:39 ID:??? AAS
>>65
成程ちょっと納得
じゃあデザパの勉強として
DBのリファクタリングにチャレンジしてみる
70: 03/12/02 06:42 ID:??? AAS
>>47
＞「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
「しんどい」仕事をふやさんでも・・・。
71: 03/12/02 06:42 ID:??? AAS
>>69
リファクタリングとチューンナップを一緒こたんにしてないか？
72(2): 03/12/02 06:46 ID:??? AAS
リファクタリングって再利用しやすいようにメソッド名を適切に書き換えたりするくらいじゃないの？
ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。
それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。
73: 03/12/02 08:27 ID:1mz3fQJ8(1) AAS
>67
パターンランゲージってそういった経験を文書化するものじゃなかったっけ？
>PHP/DesignPattern
horde の人とかデザインパターンを結構意識して使っている様だよ。
PEARだったらLog関連のクラスがGoF適用例として参考になると思う。
74: 03/12/02 10:58 ID:??? AAS
PEAR みたいなダサいもん、参考にすんなよ。
上下前次1-新書関写板覧索設栞歴
あと 96 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s