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

1 ：03/11/22 〜 最終レス ：12/05/28

ｹﾞｯﾁｭｰﾎﾟﾝ

2 ：

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

3 ：

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

4 ：

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

5 ：

>>4
で？

6 ：

サーブレットは知らんがCGI、PHPあたりだとだいたい
フォームデータ処理
if
　エラー表示１
else if
　エラー表示２
・・・
else if
　処理１
　フェーズ１表示
else if
　処理２
　フェーズ２表示
・・・・
って感じになるな

7 ：

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

8 ：

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

9 ：

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

10 ：

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

11 ：

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

12 ：

PHP関連でそういった事を解説してるサイトなかった？>WEBPrograming/DesignPattern
Stateパターンでログイン・ユーザの認証状態を管理する。etc
コーディングに特化しない話題でもいいなら、
WEB関連&&デザインパターンという事で、こんなサイトも。
http://www.designpattern.lu.unisi.ch/index.htm

13 ：

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

14 ：

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

15 ：

>>13
GOFの実装例なら、すでに幾つかありますね。
http://www.perldesignpatterns.com/
Perl5 や PHP4 にはインターフェースのための構文は用意されていないので、
(標準では)Javaみたいにインターフェースで定義したメソッドの実装を強制する事は出来ません。
多くのサンプルでは、インターフェース代わりに空メソッドを定義しているだけか、
実行時にメソッドが実装されていなければ終了する。と、いったものが殆んどの様です。
インターフェースを継承したクラスがそのメソッドを実装しているか確認したいのであれば。
perlについては、CPANにコンパイル時にインターフェースをチェックするモジュールがあります。
PHPでは、PHP5からインターフェースが導入されています。

16 ：

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

17 ：

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

18 ：

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

19 ：

>>18
＞Perl PHP Rubyじゃインターフェース無いし
プロトタイプベースだからいらんでしょ。アホか。
＞GUIもHTML吐いて作るわけだし、
むしろその辺のGUI部品より融通が利くわけだが。
後、J2EEとかASP.NETはWebプログラミングに入らないんですか？
完全無料主義者のあなたの中では。

20 ：

オブジェクト指向が必要なほど大規模になることもなく
やっぱり>>6みたいなものになっちまうのか
>>6を汎用的に書ければいいんだけど

21 ：

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

22 ：

>>20
一連の処理をひとつのアプリケーションとし、
各処理をそのアプリケーションの状態とみなすと、
Stateパターンを適応できますね。perlのCGI::Application みたいに。
勿論、非オブジェクト指向でも同様の処理は可能です。
ハッシュ等にキーと処理へのポインタを登録し、
与えられたキーの処理を呼び出すといった方法で、冗長な分岐から解放されます。
ところで、ウェブプログラミングで*使える*(eq 有用な？)デザインパターンって、
例えばどんなの？

23 ：

Webプログラミングの場合、GUIより、モデルやコントローラ周りでの
プログラミングでデザインパターンを多用するケースが多い気が。
結城 浩著書の本は役立ってます。

24 ：

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

25 ：

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

26 ：

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

27 ：

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

28 ：

フォームデータ処理
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 ：

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

30 ：

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

31 ：

>>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 ：

>> 23
アプリケーションサーバや、フレームワーク内でなら使われてる例は多いよね。GOFに限らず。
うーん、OOP/GOF な話題がメインなのかな、ここ？
WEBパターンとかの話題はスレor板違い？
http://www.c2.com/cgi/wiki?WebsitePatterns

33 ：

>>31
非オブジェクト指向言語でオブジェクト指向ごっこしたら大体は破綻するけどね。
言語もパターンも使いよう。
あんたの実力はソースコードレビューではなく客先試験で発揮して下さいよって感じになりかねない。

34 ：

25です。
>>31
ますます分からなくなりました。
これって特殊な例じゃない？

35 ：

>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め

36 ：

>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め 　　　　 だってよ。(w

37 ：

>>34
だからぐぐれよ
解説サイトいくらでもあるだろ
それか本かって読め 　　　　 だってよ。(w 　　　　 だってよ。(w

38 ：

PEARのソースコードは
デザパの勉強なるよ

39 ：

>>35-37みたいなのはプロトタイプパターンなのかな

40 ：

いまだに（ｗとか使う奴いるんだな・・・

41 ：

（ｗ

42 ：

ごめん、混乱させるような事言っちゃたかな。>25
http://www.hyuki.com/dp/dpfaq.html DesignPatterns FAQ日本語訳
パターンとは、あるコンテキスト（状況・背景）上の問題に対する一つの解決策。
繰返し発生するコンテキストは、フォームデータ処理などで発生する if else の条件分岐 like >6 >28
問題は、条件分岐の文にbugが混入しやすい事
解決策の一つは、>22 冗長な分岐を排除する。
これなら、オブジェクト指向でなくとも、ハッシュの様なデータ構造さえ使えれば適用できるでしょう？
これだけでは不十分で、これ以外にもこのパターンはどう言った時に適用すると良いとか、
適用した場合にどういった状況になるか、他に考慮するべき事もパターンに記述されます。
詳しくはパターン・ランゲージについて調べてみて。
"パターン"が理解出来たら、デザインパターンはすぐ理解出来ると思う。でも
単純に、すべてのクラスの組合せがデザインパターンと呼ばれるわけではない。（FAQにもそう書かれている）
"パターン"として有益な情報に成り得るのは、特定の条件の元の問題に対して。
組合せを指して"パターン"と呼んでいるのではないので。
デザインパターンの考え方は、オブジェクト指向をサポートしていない言語にとっても有用だと思う。
別に非OOP言語でのOOを推奨しているわけではないよ。>18 >19 >24 に対するフォローのつもり。>32

43 ：

ｺｿｰﾘとデザインパターンって何と聞いていいですか

44 ：

>>38
phpにおいて、というならまぁそうなのかもな。
リファクタリングされてないようなのがいっぱいあるけど。
なんか重いし、無駄が多いし、好きになれない

45 ：

>>44
＞リファクタリングされてないようなのがいっぱいあるけど。
は再利用の際の技であり成果物にわざわざ適用しても仕方ないのでは？

46 ：

>>44
実運用で使うようなモジュールはだいたい限られてるし、
そういうモジュールはよくメンテされてて
実用的で使えるのは結構あると思うけど。
ライブラリからリファクタリングしないと
重かったりして困るようなパフォーマンス命な
仕事なんてやったこと無いので
そういう時に使うべきかどうかというのは
判断が必要かもしれないけど

47 ：

>>46
だな。
なんらかのライブラリ群や、フレームワークを使ったとき、
ハード資源消費量は、無駄な機能の占める割合が高かったりするもんな。
それでも、漏れらは使うのさ。
信頼性のあるライブラリだし、開発コストが下がるから。
客から動作がにぶくなってきたって、言われたら、
「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
宇摩ー。

48 ：

>>47
自作自演。

49 ：

>>31よりもっと使えるやつｶﾓﾝ
実際modeで分離なんて簡単にはいかない

50 ：

>>48
してないっす
>>49
Webで現実的な問題はやっぱり時間
金銭的なコストというよりも時間のコストが
惜しいケースが多い
（もちろんそれが金銭的なコストにも
繋がってくるのはそうなのだろうけど）
PHPは大規模なwebアプリにも通用するとは思うけど
確かにフレームワーク的なものは発展中
だからこそPEARがその役割を担っていくと考えてる
PHP5ではよりPEARの役目は大きくなると思う

51 ：

>>50
PHPで大規模システムって無謀だと思う。

52 ：

>>49
commandパターンで実装
>>50
モノにもよるんじゃない
パフォーマンスも求められるものはキツいかもしれないが
ただ単に規模だけが大きいんなら
PHPでも十分メンテナンスしやすい
再利用性そこそこのもんはちゃんと作れると思う

53 ：

>>52
commandパターンがどう使えるのかぜんぜんわかんね

54 ：

>>46
リファクタリングの目的はパフォーマンスを多少犠牲にしても
メンテしやすいコードを作ることだよ。

55 ：

>>53
じゃあ使わんでいいよ、それだけのもんだ
なんで使えるのかなんで使うと得するのか
調べるコストをかけれないなら
最初から使わないのも選択のひとつ

56 ：

>>55
どーせ言ってみただけなんだろぅ？

57 ：

>>56
ああもちろんだ
俺も別に完全になんか理解してるわけない
つーか何しようとしてるか知らんが
その>>49のmode毎にたいそうな処理が
あるならともかくどうせおまえらの事だから
書き込みか確認かとかそんなだろ
なら>>6で別にいいよ
command毎にクラス作って別々の実装のコード書いて
呼び出しが $com->exec(〜) に一見なったところで
>>6がダサいからと単純に割り切るような奴が
中身実装しても良くなるとは思えん

58 ：

＞>>6がダサいからと単純に割り切るような奴が中身実装しても良くなるとは思えん
この部分には全く根拠がないし、見当外れだな

59 ：

>>6
なが〜い関数無しのスクリプトが見えます・・・。

60 ：

最近WebProg飽きたからやってないけど、昔はこんな感じに組んでたよ。
勝手にSDM-VCモデルとか呼んでたけど。
後から調べたら似たような思想の設計法とかやたらとあってちょっと欝。
S:ストレージ
ファイルとかDBとかを同じメソッドでアクセスできるようにするためのラッパクラス。
三層スキーマの内部スキーマ相当でODBCとかと似たような概念。
ここをモジュール化することで次回から使い回しが可能。
D:データ
ストレージに保存するエンティティ（データ）クラス。
同概念スキーマ相当。JDBC的な考え方。
Sを差し替えるだけで様々な媒体に永続化が可能なため移植が楽に。
M:モデル
言うまでもなく、MVCのM。
ビューに依存しないロジックを提供する。
VC:ビュー&コントローラ
リストボックスとか汎用的な部品だとVとCの分離には激しく意味があると思うが
オーダ特化のVはむしろCと一緒に管理した方が便利という判断でいっしょこたんに。
マンマシンインターフェースを担当する。

61 ：

>>60 おれもそういう経験あるよ。
有名なモデリングパターンや、デザインパターンを知らかったとき、
もっと効率良く開発したいと心掛けながら、設計していたら、
結局有名なパターンと同じ方法で設計してた。

62 ：

>>59
（　´,_ゝ｀）ﾌﾟｯ

63 ：

>61
質問いいかな？
MVCとかってパターンランゲージの用語で言う「パターン」に含まれるの？
モデリング・パターンのパターンとか？MVCにもパターンの様なもの
（どういった時にMVCで設計するといい。とか）の記述がある？
自分のデザインパターンに対する認識が他の人とは違ってるよーな気がしてきた。
「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。

64 ：

>>63
>>6をパターンとかほざいてるんだからなんでもありっしょ。

65 ：

>>46-47
いや、>>38でデザパの勉強になるといわれての>>44では？
俺も好きになれない。
よく使いたいと思うものに無駄が多いように見えるから。AuthしかりDBしかり。
sql作るのは Builder & Directorでやって欲しいし、
CREATE 〜なんて AdaptorやDecoratorでいい。
メソッドの中にベタ書きだし、クエリ発行関数はあちこちに散らばってるし。
詳しいわけじゃないけど、これがデザインパターンといわれるとなんか抵抗あるわけですよ。
それでもPEARスレはのぞいちゃうんだけどね。

66 ：

無駄が多いんだけならいいんだよ。その分汎用性が高くなってるわけだし。
でもダサいコードが多いじゃん。あれなら Perl で CPAN の方が(ﾟДﾟ)ｳﾏｰ

67 ：

＞「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
＞等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。
それは、多くの経験の集約から「このパターンはこのケースに使える」というのが出てくるのであって、
今は「こういうパターンがあるんじゃね？」って段階だろ。このスレ的には

68 ：

>>60
いわゆるDAOとValueObjectですね。
Javaだとそのあたりを担ってくれるフレームワークも多いけど、
PHPなんかだとこれからの分野なのかな。

69 ：

>>65
成程ちょっと納得
じゃあデザパの勉強として
DBのリファクタリングにチャレンジしてみる

70 ：

>>47
＞「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
「しんどい」仕事をふやさんでも・・・。

71 ：

>>69
リファクタリングとチューンナップを一緒こたんにしてないか？

72 ：

リファクタリングって再利用しやすいようにメソッド名を適切に書き換えたりするくらいじゃないの？
ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。
それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。

73 ：

>67
パターンランゲージってそういった経験を文書化するものじゃなかったっけ？
>PHP/DesignPattern
horde の人とかデザインパターンを結構意識して使っている様だよ。
PEARだったらLog関連のクラスがGoF適用例として参考になると思う。

74 ：

PEAR みたいなダサいもん、参考にすんなよ。

75 ：

>>72
いやもっとあるよ。オレは詳しくはないけどね。
もちろんリファクタリングするにはテストファーストが重要だから。
それがなけりゃダメ。

76 ：

デザインパターンて何？

77 ：

>>76 ずばり！システムデザインのパターンです。

78 ：

なんでデザインなんだろう。

79 ：

デザイン≒設計

80 ：

>>79

81 ：

デザインパターン≒下絵
？→？→？
↓ ↑ ↑
？→？←？

82 ：

>>72
http://objectclub.esm.co.jp/UnderstandingRefactoringByChart/

83 ：

おすすめの書籍を教えてよ。
リファクタリング＋デザインパターンもの？

84 ：

　　　　　　　Java言語で学ぶデザインパターン入門

85 ：

昔Observerを使ったMVCを知って、
『こりゃいいや！』ってWebプログラムで使おうとして
かえってごちゃごちゃになった。

86 ：

あ、本題書き忘れた。
Compositeパターンはツリー型掲示板なんかにうってつけじゃないの？

87 ：

>>86
そうですか？
なんかただの木構造と混同してないか？

88 ：

>>87
ん？……あ、そうか。
スレッド(トピック？)の下にスレッドがあるような再起構造じゃないや。
でも、子記事を持つものをComposite、持たないものをLeafと見立てて
使えないかな？
それとも俺何か勘違いしてるかな？

89 ：

>>87
木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern
>>79,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？
solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。
デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。
>>85
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。
例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。
クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。

90 ：

>>89
めんどいから要約してくれ。3行位に。大体それくらいの情報量だろ？

91 ：

無理。
ジャンプ＆フローで要約性がないパターン。

92 ：

>>90
>>89を要約すると「お前らもっと勉強しろ、俺はこれだけ物知りだ」になります

93 ：

>>89
ああ、ごめん、言葉が足りなかった。
>>85は
Observerを使ったMVCはGUIなソフトとかには使えるけど
Webアプリケーションなんかには向かないぞ、気をつけろー。
Webアプリケーション用のMVCはJ2EEとかを参考にしろー。
って意味だったんです。

94 ：

CGIはGoF的なデザインパターン使って作っても
オブジェクト生成して一回で捨てちゃうもんな

95 ：

こんな100レス近くも語ってて
結局>>6を改善することはできないんですか？

96 ：

>>94
再利用できる要素はいっぱいあるんだけどな。
ファイル操作とか毎回組んでも面倒くさいしバグの入り込む余地があるしろくな事がないと思うよ。

97 ：

>>95
>>6みたいなのが良いとは思ってないが、
>>6の代行になる優れたコードがあったとしても
結局>>6レベルくらいで求められる規模のwebAPPの場合
実際のところ>>6が一番速く書けて一番シンプルで
一番速く動くコードだったりしちゃわないか

98 ：

>>97
再利用生が抜けてるよ。

99 ：

>>96
ファイル周りで、こういう処理にはこういうパターンがいいよ、みたいのある？
趣味でCGIスクリプト作ってるけど結局ファイル入出力が処理の中心で、
ここをシンプルに書ければだいぶ綺麗になるんだけどなぁ。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

●CGI作成に愛の手を・・・● (159)
セキュリティースレッド (239)
【Python】Webフレームワーク Djangoスレ Part2 (131)
【激速】mod_perl SpeedyCGI FastCGI【激速】 (849)
ギコタクの「だから逝ってないでしょ」出張所 (412)
【PHP】フレームワークMapleに舌鼓 (461)
--log9.info------------------
チルドレンの子供の時の家庭での役割 (384)
(･ω･)(･ω･)(･ω･)生まれたから生きてんだけど (745)
失笑恐怖症-面白くもないのに笑ってしまう病気 (298)
自殺決行日までの僅かな日々を語るスレ Part33 (747)
こういう名前の薬が飲みたい (808)
【前世】スピリチュアルとメンヘル【カルマ】 (356)
【既にｼﾗﾇは】常識を優しく教えるスレ☆2【恥の年】 (745)
ｽﾎﾟｰﾂｼﾞﾑ通いでﾒﾝﾍﾙ状態を改善できた☆Part8 (832)
【オン会】メンヘラ同士酒飲もうぜ！98次会 (877)
韓国中国北朝鮮が好きなメンヘラ (530)
自殺遺族あつまれ２ (306)
【むしろ】精神科いっても治んないよね【薬漬け】 (267)
大金があれば自分の問題は解決すると思う人 (221)
面白いことを書き込んで自殺者を減らすスレ13 (676)
みんなが出ちゃうスレ(~o~)　●●●●●● (667)
【ぼくは】(｀・ω・´)生きとる！5【ここにいる】 (946)
--log55.com------------------
京都の高校野球 111
【史上最強地区】関東の高校野球882【選抜へ向け無敵艦隊出航！】
千葉県の高校野球 Part840
東海大菅生
高知の高校野球119【9/14〜秋季大会】
長野県の高校野球Part4〈いざ北信越制覇〉
関東のシニアボーイズ進路 part96
大産大高校