ウェブプログラミングで使えるデザインパターン
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/11/22 06:56ID:Lh+gL3bz0052nobodyさん
03/11/30 00:57ID:???commandパターンで実装
>>50
モノにもよるんじゃない
パフォーマンスも求められるものはキツいかもしれないが
ただ単に規模だけが大きいんなら
PHPでも十分メンテナンスしやすい
再利用性そこそこのもんはちゃんと作れると思う
0055nobodyさん
03/11/30 01:49ID:ENFs/Hl7じゃあ使わんでいいよ、それだけのもんだ
なんで使えるのかなんで使うと得するのか
調べるコストをかけれないなら
最初から使わないのも選択のひとつ
0057nobodyさん
03/11/30 02:35ID:ENFs/Hl7ああもちろんだ
俺も別に完全になんか理解してるわけない
つーか何しようとしてるか知らんが
その>>49のmode毎にたいそうな処理が
あるならともかくどうせおまえらの事だから
書き込みか確認かとかそんなだろ
なら>>6で別にいいよ
command毎にクラス作って別々の実装のコード書いて
呼び出しが $com->exec(〜) に一見なったところで
>>6がダサいからと単純に割り切るような奴が
中身実装しても良くなるとは思えん
0060nobodyさん
03/11/30 10:01ID:???勝手にSDM-VCモデルとか呼んでたけど。
後から調べたら似たような思想の設計法とかやたらとあってちょっと欝。
S:ストレージ
ファイルとかDBとかを同じメソッドでアクセスできるようにするためのラッパクラス。
三層スキーマの内部スキーマ相当でODBCとかと似たような概念。
ここをモジュール化することで次回から使い回しが可能。
D:データ
ストレージに保存するエンティティ（データ）クラス。
同概念スキーマ相当。JDBC的な考え方。
Sを差し替えるだけで様々な媒体に永続化が可能なため移植が楽に。
M:モデル
言うまでもなく、MVCのM。
ビューに依存しないロジックを提供する。
VC:ビュー&コントローラ
リストボックスとか汎用的な部品だとVとCの分離には激しく意味があると思うが
オーダ特化のVはむしろCと一緒に管理した方が便利という判断でいっしょこたんに。
マンマシンインターフェースを担当する。
0061nobodyさん
03/11/30 12:35ID:???有名なモデリングパターンや、デザインパターンを知らかったとき、
もっと効率良く開発したいと心掛けながら、設計していたら、
結局有名なパターンと同じ方法で設計してた。
0063nobodyさん
03/12/01 02:53ID:i/vnv4B8質問いいかな？
MVCとかってパターンランゲージの用語で言う「パターン」に含まれるの？
モデリング・パターンのパターンとか？MVCにもパターンの様なもの
（どういった時にMVCで設計するといい。とか）の記述がある？
自分のデザインパターンに対する認識が他の人とは違ってるよーな気がしてきた。
「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。
0065nobodyさん
03/12/01 10:49ID:???いや、>>38でデザパの勉強になるといわれての>>44では？
俺も好きになれない。
よく使いたいと思うものに無駄が多いように見えるから。AuthしかりDBしかり。
sql作るのは Builder & Directorでやって欲しいし、
CREATE 〜なんて AdaptorやDecoratorでいい。
メソッドの中にベタ書きだし、クエリ発行関数はあちこちに散らばってるし。
詳しいわけじゃないけど、これがデザインパターンといわれるとなんか抵抗あるわけですよ。
それでもPEARスレはのぞいちゃうんだけどね。
0066nobodyさん
03/12/01 11:09ID:???でもダサいコードが多いじゃん。あれなら Perl で CPAN の方が(ﾟДﾟ)ｳﾏｰ
0067nobodyさん
03/12/01 13:06ID:???＞等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。
それは、多くの経験の集約から「このパターンはこのケースに使える」というのが出てくるのであって、
今は「こういうパターンがあるんじゃね？」って段階だろ。このスレ的には
0068nobodyさん
03/12/01 19:00ID:???いわゆるDAOとValueObjectですね。
Javaだとそのあたりを担ってくれるフレームワークも多いけど、
PHPなんかだとこれからの分野なのかな。
0072nobodyさん
03/12/02 06:46ID:???ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。
それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。
0073nobodyさん
03/12/02 08:27ID:1mz3fQJ8パターンランゲージってそういった経験を文書化するものじゃなかったっけ？
>PHP/DesignPattern
horde の人とかデザインパターンを結構意識して使っている様だよ。
PEARだったらLog関連のクラスがGoF適用例として参考になると思う。
0074nobodyさん
03/12/02 10:58ID:???0076nobodyさん
03/12/02 14:00ID:c/j/bWHB0079nobodyさん
03/12/02 19:32ID:/3byaW6X0081nobodyさん
03/12/02 21:34ID:???？→？→？
↓ ↑ ↑
？→？←？
0082nobodyさん
03/12/04 14:10ID:???http://objectclub.esm.co.jp/UnderstandingRefactoringByChart/
0083nobodyさん
03/12/05 00:56ID:???リファクタリング＋デザインパターンもの？
0084nobodyさん
03/12/05 22:40ID:???Java言語で学ぶデザインパターン入門
0085nobodyさん
03/12/21 01:33ID:hM57n5k9『こりゃいいや！』ってWebプログラムで使おうとして
かえってごちゃごちゃになった。
0086nobodyさん
03/12/21 01:36ID:hM57n5k9Compositeパターンはツリー型掲示板なんかにうってつけじゃないの？
008885
03/12/21 13:13ID:???ん？……あ、そうか。
スレッド(トピック？)の下にスレッドがあるような再起構造じゃないや。
でも、子記事を持つものをComposite、持たないものをLeafと見立てて
使えないかな？
それとも俺何か勘違いしてるかな？
0089nobodyさん
03/12/21 15:35ID:???木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern
>>79,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？
solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。
デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。
>>85
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。
例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。
クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。
0091nobodyさん
03/12/21 15:55ID:???ジャンプ＆フローで要約性がないパターン。
009385
03/12/21 17:14ID:???ああ、ごめん、言葉が足りなかった。
>>85は
Observerを使ったMVCはGUIなソフトとかには使えるけど
Webアプリケーションなんかには向かないぞ、気をつけろー。
Webアプリケーション用のMVCはJ2EEとかを参考にしろー。
って意味だったんです。
0094nobodyさん
03/12/22 01:36ID:???オブジェクト生成して一回で捨てちゃうもんな
0096nobodyさん
03/12/22 07:37ID:???再利用できる要素はいっぱいあるんだけどな。
ファイル操作とか毎回組んでも面倒くさいしバグの入り込む余地があるしろくな事がないと思うよ。
0097nobodyさん
03/12/23 02:36ID:???>>6みたいなのが良いとは思ってないが、
>>6の代行になる優れたコードがあったとしても
結局>>6レベルくらいで求められる規模のwebAPPの場合
実際のところ>>6が一番速く書けて一番シンプルで
一番速く動くコードだったりしちゃわないか
0099nobodyさん
03/12/26 13:59ID:5BZ0FoxAファイル周りで、こういう処理にはこういうパターンがいいよ、みたいのある？
趣味でCGIスクリプト作ってるけど結局ファイル入出力が処理の中心で、
ここをシンプルに書ければだいぶ綺麗になるんだけどなぁ。
0101nobodyさん
03/12/26 23:57ID:???＞ファイルとかDBとかを同じメソッドで
＞アクセスできるようにするためのラッパクラス。
これ作ってください。
0102ヽ(´ー`)ノ
03/12/27 04:55ID:???> ＞ファイルとかDBとかを同じメソッドで
> ＞アクセスできるようにするためのラッパクラス。
> これ作ってください。
Perl の DBI に当たるクラスって Ruby には無いの？
0104nobodyさん
03/12/27 22:23ID:???0105nobodyさん
04/01/03 11:48ID:2WhaiS3phttp://www.lyricfathom.com/pukiwiki/pukiwiki.php?Web%A5%A2%A5%D7%A5%EA%A5%B1%A1%BC%A5%B7%A5%E7%A5%F3%A4%C7%A4%CEBridge%A5%D1%A5%BF%A1%BC%A5%F3
0106nobodyさん
04/01/03 14:16ID:/y0BIE8shttp://www.phppatterns.com/
0107nobodyさん
04/01/05 19:45ID:???典型的な例が Singleton。
0108nobodyさん
04/01/05 20:23ID:???$a = NULL;
function GetSameObject(){
global $a;
if($a == NULL){
$a = new SameObject();
}
return $a;
}
0109nobodyさん
04/01/07 09:41ID:???だから、そういう小汚いコード書かなきゃイカンから言語として機能が足りてないんだろ。
PHP5 だと static あるから Singleton は書けるようになるが…それでもどうかと思う。
0110nobodyさん
04/01/07 18:00ID:???PEAR パッケージでよく使われてますが、 PHP4 でも普通に書けますよ。
class Hoge
{
function &singleton()
{
static $instance;
if (!isset($instance)) {
$instance = new Hoge;
// $instance = HogeHoge::factory;
}
return $instance;
}
$instance = &Hoge::singleton();
0111107
04/01/08 05:49ID:???>>109 の言う「小汚い」部類じゃないかね、そのコードは。
クラス内唯一のインスタンスなんだから、論理的に言えばクラスが static 変数として持つべきだろう。
> PHP5 だと static あるから Singleton は書けるようになるが
と言っている時点で >>109 の言いたい事は自明だと思うんだが…。あんた大丈夫か？
PEAR のコードや Do You PHP にあるデザインパターンのサンプルでも良く見掛けるが、
PHP4 自体の機能が足りずに他の言語ではしなくていいような事をしている点がいくつもある。
少くとも俺は PHP はオススメしない。
0113nobodyさん
04/01/08 06:44ID:???てことはCはダメ言語でerronoなんて使ってるunixは目も当てられないって事になるのだろうか。
そんなことだからいつまでもプログラマ + Web特化なんだな。
0114nobodyさん
04/01/08 06:47ID:???0116110
04/01/08 09:17ID:???できますよ。
言語特性や制限はありますが PHP や Perl では Private メソッドも含めてそういう
ものは書く側が慣習的に守るというだけのことです。 111 さんがいうようなことも
当然ありますけど、だからといってその言語の利点があるわけですから使い分けるの
が良いというだけの話でしょう。
0117nobodyさん
04/01/08 14:14ID:???コンストラクタの実装とクラス変数に大きく依存するパターンは、
PHP の言語仕様とインピーダンスミスマッチが大きい、ということは言えそうに思う。
ただ、GoFパターン全部がそういうわけではなく、
むしろ singleton が例外的だとも言える。
つか、そもそも singleton ってウェブプログラミングで使う?
まあ、singleton 以外のパターンも今のところウェブプログラミングでの使い道が
あまり見つかってないようではあるが。
しかし、ぱっとすぐ思いつかないが、
singleton 以外でも PHP が向かないパターンはありそうな感じではある。
>>107 への宿題として、
singleton 以外で PHP が向いていないと思われるパターンを提出せよ。
「ウェブプログラミングで使える」というスレの趣旨を満たすとモアベターだが、
さすがにそこまでは難しいか。
0118nobodyさん
04/01/08 20:51ID:???一応、慣習や暗黙の了解みたいなのは理解しています。が、
言語としての機能が足りていない部分という論点に関して言えば、コードの奇麗汚いではなくて
singletonパターンの条件を完全に満たす事が出来ない点じゃないかな。と思った。
>>117
例：データベースへ接続するクラスをSingletonにする。
ウェブプログラミングでもアプリケーションサーバ等フレームワークにはよく使われてるよ。
0120nobodyさん
04/01/08 23:24ID:???気を付けてグローバル変数を使用するのと早々大差はない。
0121nobodyさん
04/01/09 07:36ID:???// |:!
//,. -/r‐- ､| !
/,/ ./ | _」 ﾄ､
/.＼`/ |二...-┘ ヽ
. i ,.>､;／ｰ- ､ l
! ∠..＿;'＿＿＿_＼ |
,!ｲ く二>,.、 <二＞｀＼.､ヽ.
／'´レ--‐'ﾉ. `ｰ---- ､ |＼ ヽ、
＼ `l (!" Jfヽ! `''-;ゝ 大佐ではない
`‐､jヽ ヾﾆﾆ> ﾞｲ" }_,,. ‐''´
`´＼ ｰ ／ ,ィ_}
. |_ `ー ''´ ＿｣'
, ー‐-‐‐‐--''.‐''゛,,;,,...: ゛''-､､,;,,
,ｨ'゛ ゛゛""' ゛"'''-､
/ ヽ
/ '、
l l
. l i. l
l :i. ヽ.:.:...:.:: "'
. l .:l ヽ.:.::... "''､
. l. .:l ヽ.:..:. `'､
l ::l: ';.:.:..... ヽ
l .:l.:.. .:ｨ.):.:. l.:.:.: .:.ヽ、
. l .:l..: ''ー.: .:.:l.:.:..:..:: .:i'゛
0122nobodyさん
04/01/09 10:45ID:???フレームワーク内で使われるのはわかるが
DBのコネクションプールはそうやってフレームワークが管理してくれるはずだから
ユーザがコード書く段階では気にしなくていいぢゃん。
Perl ですら mod_perl + Apache::DBI 使えばいいし。
と思ったが、よくよく考えてみたら、PHP にはコネクションプールが無いのか。
それは確かに問題だな。
0123110
04/01/09 11:34ID:???私の知る限りでは Apache::DBI はコネクションプールをしているわけではな
くて PHP の持続的接続と同等の機能を提供するはずです。
つまり DSN 毎にコネクションを維持するだけ (さらにプロセス毎に) だと理
解していますが。
さらにコネクションプールは SQL Relay 等で実現できますよ。
0124nobodyさん
05/01/27 00:47:17ID:???どうしればいいでしょうか。
早くオブジェクト脳になりたいんです！
0126nobodyさん
2005/04/03(日) 21:00:04ID:???0127nobodyさん
2005/04/24(日) 12:25:02ID:???0128nobodyさん
2005/05/02(月) 21:38:03ID:M34Qp7Tn変更なしに機能を追加したりするときにアダプタっていう
デザインパターンを使うのかな？使い方間違ってる？
0129nobodyさん
2005/05/02(月) 22:18:31ID:???http://pc8.2ch.net/test/read.cgi/tech/1095388499/
0130nobodyさん
2005/05/03(火) 22:22:38ID:???実は仕事で既に動いているPHPプログラム改修作業をすることに
なったのですが、
・非常に見づらいソース。開発者は既に退社＆ドキュメントは無し。
・納期は短いのでリコーディングすることはできない。
・動作自体には問題はなく、現在正常に稼動中。
・機能拡張もあり。
という状況です。ソースが非常に見づらく保守性が著しく低いのと
機能拡張は大幅な仕様変更になるので、できればリコーディングしたい
ところなのですが、納期も無いことですし、何より現在問題なく
稼動中なのでそれはできません。
そこでなるべく既存のクラスに手を加えずに、機能拡張をしたい
という感じです。
このような場合、既存のクラスを継承させた新しいクラスを作り、
動いている部分は利用しつつ、新規の仕様に合わせた設計に作り変える
というやりかたを考えているのですが、これは別にデザインパターンという
わけではなくて、ただのOOPの継承を使ってるだけということですかね。
ちなみに、上記のような場合皆さんならどのような手法を取りますか？
識者のご意見をお聞かせいただけたらと思います。
0131nobodyさん
2005/05/05(木) 23:01:05ID:???漏れなら先ず上司に現状を報告し、指示を仰ぐな
1.現状のプログラムが如何に問題点の多い物であるか
2.前任者の無能さを叩き、リコーディングの必要性の訴え
3.リコーディングすれば納期に間に合わせる事は難しい。
しかし前任者のプログラムに手を入れた場合、（極端に保守性が悪いので）変更によって障害が起きる可能性が高く、納期が大幅に遅れる危険がある。
以上を伝えて今後の方針を決め、増援を求めるなり何なり対策を協議して･･
（要は、「責任逃れの道はちゃんと作っておけよ」と）
0133nobodyさん
2005/05/28(土) 13:42:10ID:???0134nobodyさん
2005/06/11(土) 13:52:15ID:???0135nobodyさん
2005/06/23(木) 01:29:49ID:l0fPbzln>>6のかわりってこれでいいんじゃね？
0136nobodyさん
2005/07/14(木) 05:02:59ID:Dw3R1Zsmみんなデザインパターンってあまり知らないのか？
0137nobodyさん
2005/07/14(木) 05:09:10ID:???0138nobodyさん
2005/07/14(木) 05:35:55ID:???0139nobodyさん
2005/07/14(木) 20:33:00ID:???0140nobodyさん
2005/07/14(木) 21:17:21ID:???0141nobodyさん
2005/08/09(火) 19:13:09ID:1DO6YyCD後者の場合、Webは選択肢の一つに過ぎないけど参考になる。
これらをPHPに適用するとどうなるか考えるのも面白い。
0142nobodyさん
2005/09/02(金) 22:29:06ID:???0143nobodyさん
2005/09/08(木) 20:14:04ID:UAazRTehhttp://www.phparch.com/shop_product.php?itemid=96
とりあえずPHP向けの本が出てるから皆買おう。
そうでなきゃ話しも出来ん。
0144nobodyさん
2005/09/09(金) 01:34:49ID:???0147nobodyさん
2005/09/19(月) 10:34:02ID:???0149nobodyさん
2005/09/20(火) 02:45:05ID:???ペーパーバッグとペーパーバック間違えてた
ビートルズの曲もペーパーバッグライターと思ってた…
0150nobodyさん
2005/09/20(火) 02:46:20ID:???よかった他にもたくさんいた…
0151nobodyさん
2006/01/19(木) 19:25:49ID:tf3J2l5IStrategy、あたりを使うねぇ。
■ このスレッドは過去ログ倉庫に格納されています