ウェブプログラミングで使えるデザインパターン (170ﾚｽ)
上下前次1-新
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(〜) に一見なったところで
省2
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的な考え方。
省8
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
リファクタリングって再利用しやすいようにメソッド名を適切に書き換えたりするくらいじゃないの？
ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。
それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。
上下前次1-新書関写板覧索設栞歴
あと 98 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s