ウェブプログラミングで使えるデザインパターン (170ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
1(3): 03/11/22 06:56 ID:Lh+gL3bz(1) AAS
ｹﾞｯﾁｭｰﾎﾟﾝ
6(12): 03/11/23 19:42 ID:??? AAS
サーブレットは知らんがCGI、PHPあたりだとだいたい
フォームデータ処理
if
エラー表示１
else if
エラー表示２
・・・
else if
処理１
フェーズ１表示
else if
処理２
フェーズ２表示
・・・・
って感じになるな
18(3): 03/11/27 02:15 ID:??? AAS
ウェブプログラミングじゃあんまGoF通用しないんじゃね？
Perl PHP Rubyじゃインターフェース無いし、GUIもHTML吐いて作るわけだし、
インスタンスを次のセッションで使うのもしんどいじゃん
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);
}
}
34(3): 03/11/27 23:54 ID:??? AAS
25です。
>>31
ますます分からなくなりました。
これって特殊な例じゃない？
44(3): 03/11/29 13:48 ID:??? AAS
>>38
phpにおいて、というならまぁそうなのかもな。
リファクタリングされてないようなのがいっぱいあるけど。
なんか重いし、無駄が多いし、好きになれない
46(4): 03/11/29 22:56 ID:??? AAS
>>44
実運用で使うようなモジュールはだいたい限られてるし、
そういうモジュールはよくメンテされてて
実用的で使えるのは結構あると思うけど。
ライブラリからリファクタリングしないと
重かったりして困るようなパフォーマンス命な
仕事なんてやったこと無いので
そういう時に使うべきかどうかというのは
判断が必要かもしれないけど
47(3): 03/11/29 23:21 ID:??? AAS
>>46
だな。
なんらかのライブラリ群や、フレームワークを使ったとき、
ハード資源消費量は、無駄な機能の占める割合が高かったりするもんな。
それでも、漏れらは使うのさ。
信頼性のあるライブラリだし、開発コストが下がるから。
客から動作がにぶくなってきたって、言われたら、
「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
宇摩ー。
49(3): 03/11/30 00:32 ID:Fs/0s5IP(1) AAS
>>31よりもっと使えるやつｶﾓﾝ
実際modeで分離なんて簡単にはいかない
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と一緒に管理した方が便利という判断でいっしょこたんに。
マンマシンインターフェースを担当する。
85(3): 03/12/21 01:33 ID:hM57n5k9(1/2) AAS
昔Observerを使ったMVCを知って、
『こりゃいいや！』ってWebプログラムで使おうとして
かえってごちゃごちゃになった。
89(3): 03/12/21 15:35 ID:??? AAS
>>87
木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern
>>79,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？
solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。
デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。
>>85
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。
例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。
クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。
107(3): 04/01/05 19:45 ID:??? AAS
PHP、言語として機能が足りてないからデザパタに向いてないよ。
典型的な例が Singleton。
110(4): 04/01/07 18:00 ID:??? AAS
>>109
PEAR パッケージでよく使われてますが、 PHP4 でも普通に書けますよ。
class Hoge
{
function &singleton()
{
static $instance;
if (!isset($instance)) {
$instance = new Hoge;
// $instance = HogeHoge::factory;
}
return $instance;
}
$instance = &Hoge::singleton();
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.369s*