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

ｹﾞｯﾁｭｰﾎﾟﾝ

>>44
実運用で使うようなモジュールはだいたい限られてるし、
そういうモジュールはよくメンテされてて
実用的で使えるのは結構あると思うけど。

ライブラリからリファクタリングしないと
重かったりして困るようなパフォーマンス命な
仕事なんてやったこと無いので
そういう時に使うべきかどうかというのは
判断が必要かもしれないけど

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

>>47
自作自演。

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

>>48
してないっす

>>49
Webで現実的な問題はやっぱり時間
金銭的なコストというよりも時間のコストが
惜しいケースが多い
（もちろんそれが金銭的なコストにも
繋がってくるのはそうなのだろうけど）

PHPは大規模なwebアプリにも通用するとは思うけど
確かにフレームワーク的なものは発展中
だからこそPEARがその役割を担っていくと考えてる
PHP5ではよりPEARの役目は大きくなると思う

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

>>49
commandパターンで実装

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

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

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

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

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

>>56
ああもちろんだ
俺も別に完全になんか理解してるわけない

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

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

>>6

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

最近WebProg飽きたからやってないけど、昔はこんな感じに組んでたよ。
勝手にSDM-VCモデルとか呼んでたけど。
後から調べたら似たような思想の設計法とかやたらとあってちょっと欝。

S:ストレージ
ファイルとかDBとかを同じメソッドでアクセスできるようにするためのラッパクラス。
三層スキーマの内部スキーマ相当でODBCとかと似たような概念。
ここをモジュール化することで次回から使い回しが可能。

D:データ
ストレージに保存するエンティティ（データ）クラス。
同概念スキーマ相当。JDBC的な考え方。
Sを差し替えるだけで様々な媒体に永続化が可能なため移植が楽に。

M:モデル
言うまでもなく、MVCのM。
ビューに依存しないロジックを提供する。

VC:ビュー&コントローラ
リストボックスとか汎用的な部品だとVとCの分離には激しく意味があると思うが
オーダ特化のVはむしろCと一緒に管理した方が便利という判断でいっしょこたんに。
マンマシンインターフェースを担当する。

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

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

>61
質問いいかな？
MVCとかってパターンランゲージの用語で言う「パターン」に含まれるの？
モデリング・パターンのパターンとか？MVCにもパターンの様なもの
（どういった時にMVCで設計するといい。とか）の記述がある？


自分のデザインパターンに対する認識が他の人とは違ってるよーな気がしてきた。
「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。

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

>>46-47

いや、>>38でデザパの勉強になるといわれての>>44では？

俺も好きになれない。
よく使いたいと思うものに無駄が多いように見えるから。AuthしかりDBしかり。

sql作るのは Builder & Directorでやって欲しいし、
CREATE 〜なんて AdaptorやDecoratorでいい。
メソッドの中にベタ書きだし、クエリ発行関数はあちこちに散らばってるし。
詳しいわけじゃないけど、これがデザインパターンといわれるとなんか抵抗あるわけですよ。

それでもPEARスレはのぞいちゃうんだけどね。

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

＞「パターン」のコンテキストやフォース（どういった時にそのパターンを適応するといい。
＞等といったパターンの目的や背景やその制約）の部分が抜けてる様な気がするんだけど。

それは、多くの経験の集約から「このパターンはこのケースに使える」というのが出てくるのであって、
今は「こういうパターンがあるんじゃね？」って段階だろ。このスレ的には

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

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

>>47
＞「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。

「しんどい」仕事をふやさんでも・・・。

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

リファクタリングって再利用しやすいようにメソッド名を適切に書き換えたりするくらいじゃないの？
ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。

それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。

>67
パターンランゲージってそういった経験を文書化するものじゃなかったっけ？

>PHP/DesignPattern
horde の人とかデザインパターンを結構意識して使っている様だよ。
PEARだったらLog関連のクラスがGoF適用例として参考になると思う。

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

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

デザインパターンて何？

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

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

デザイン≒設計

>>79

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

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

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

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

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

>>86
そうですか？

なんかただの木構造と混同してないか？

>>87
ん？……あ、そうか。
スレッド(トピック？)の下にスレッドがあるような再起構造じゃないや。

でも、子記事を持つものをComposite、持たないものをLeafと見立てて
使えないかな？

それとも俺何か勘違いしてるかな？

>>87
木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern

>>79,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？

solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。

デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。

>>85
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。

例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。

クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。

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

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

>>90

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

>>89
ああ、ごめん、言葉が足りなかった。

>>85は
Observerを使ったMVCはGUIなソフトとかには使えるけど
Webアプリケーションなんかには向かないぞ、気をつけろー。
Webアプリケーション用のMVCはJ2EEとかを参考にしろー。

って意味だったんです。

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

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

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

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

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

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

>>99

>>60


後、今、RubyとXML使って汎用的なCGI向きなファイルシステム書いてます。

だれか
＞ファイルとかDBとかを同じメソッドで
＞アクセスできるようにするためのラッパクラス。
これ作ってください。

> だれか
> ＞ファイルとかDBとかを同じメソッドで
> ＞アクセスできるようにするためのラッパクラス。
> これ作ってください。
Perl の DBI に当たるクラスって Ruby には無いの？

>>102
アルみたいですな。知らなんだ。
ちょっと興味があるんですが、データをCSVとかXMLに落としてくれるドライバって存在するんですか？

Ruby/DBI http://ruby-dbi.sourceforge.net/

Bridgeパターン
http://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

PHPのパターンならここが有名でしょうね。
http://www.phppatterns.com/

PHP、言語として機能が足りてないからデザパタに向いてないよ。
典型的な例が Singleton。

$a = NULL;

function GetSameObject(){
global $a;

if($a == NULL){
$a = new SameObject();
}

return $a;
}

>>108
だから、そういう小汚いコード書かなきゃイカンから言語として機能が足りてないんだろ。
PHP5 だと static あるから Singleton は書けるようになるが…それでもどうかと思う。

>>109
PEAR パッケージでよく使われてますが、 PHP4 でも普通に書けますよ。

class Hoge
{
function &singleton()
{
static $instance;
if (!isset($instance)) {
$instance = new Hoge;
// $instance = HogeHoge::factory;
}

return $instance;
}

$instance = &Hoge::singleton();

>>110
>>109 の言う「小汚い」部類じゃないかね、そのコードは。
クラス内唯一のインスタンスなんだから、論理的に言えばクラスが static 変数として持つべきだろう。
> PHP5 だと static あるから Singleton は書けるようになるが
と言っている時点で >>109 の言いたい事は自明だと思うんだが…。あんた大丈夫か？

PEAR のコードや Do You PHP にあるデザインパターンのサンプルでも良く見掛けるが、
PHP4 自体の機能が足りずに他の言語ではしなくていいような事をしている点がいくつもある。
少くとも俺は PHP はオススメしない。

>>111
デザパタの本の「はじめに」とか「概要」を読み直すことを推奨。

>>111
てことはCはダメ言語でerronoなんて使ってるunixは目も当てられないって事になるのだろうか。
そんなことだからいつまでもプログラマ + Web特化なんだな。

まぁ C はダメ言語だろうな。

>>110
クラス・メソッドを使わずnewすると普通に別のインスタンス作成出来るよね？

>>115
できますよ。
言語特性や制限はありますが PHP や Perl では Private メソッドも含めてそういう
ものは書く側が慣習的に守るというだけのことです。 111 さんがいうようなことも
当然ありますけど、だからといってその言語の利点があるわけですから使い分けるの
が良いというだけの話でしょう。

そうだなあ、singleton という、
コンストラクタの実装とクラス変数に大きく依存するパターンは、
PHP の言語仕様とインピーダンスミスマッチが大きい、ということは言えそうに思う。

ただ、GoFパターン全部がそういうわけではなく、
むしろ singleton が例外的だとも言える。

つか、そもそも singleton ってウェブプログラミングで使う?
まあ、singleton 以外のパターンも今のところウェブプログラミングでの使い道が
あまり見つかってないようではあるが。

しかし、ぱっとすぐ思いつかないが、
singleton 以外でも PHP が向かないパターンはありそうな感じではある。

>>107 への宿題として、
singleton 以外で PHP が向いていないと思われるパターンを提出せよ。
「ウェブプログラミングで使える」というスレの趣旨を満たすとモアベターだが、
さすがにそこまでは難しいか。

>>116
一応、慣習や暗黙の了解みたいなのは理解しています。が、
言語としての機能が足りていない部分という論点に関して言えば、コードの奇麗汚いではなくて
singletonパターンの条件を完全に満たす事が出来ない点じゃないかな。と思った。

>>117
例：データベースへ接続するクラスをSingletonにする。
ウェブプログラミングでもアプリケーションサーバ等フレームワークにはよく使われてるよ。

>>117
宿題も糞も、PHP のデザインパターンのサンプルコード読めよ。
その辺の問題点も全部書いてるわ。

まぁ、極論すればグローバル変数をラップしただけという代物だ。
気を付けてグローバル変数を使用するのと早々大差はない。

>>118
フレームワーク内で使われるのはわかるが
DBのコネクションプールはそうやってフレームワークが管理してくれるはずだから
ユーザがコード書く段階では気にしなくていいぢゃん。
Perl ですら mod_perl + Apache::DBI 使えばいいし。

と思ったが、よくよく考えてみたら、PHP にはコネクションプールが無いのか。
それは確かに問題だな。

>>122
私の知る限りでは Apache::DBI はコネクションプールをしているわけではな
くて PHP の持続的接続と同等の機能を提供するはずです。
つまり DSN 毎にコネクションを維持するだけ (さらにプロセス毎に) だと理
解していますが。

さらにコネクションプールは SQL Relay 等で実現できますよ。

一生懸命読んだけど23の中の一個も理解できませんでした
どうしればいいでしょうか。
早くオブジェクト脳になりたいんです！

>>124
オブジェクト指向を学ぶ

保守

PHP5だとデザインパターンも生きてくるのかな？

プログラムの改修作業で、既存の動いているクラスを
変更なしに機能を追加したりするときにアダプタっていう
デザインパターンを使うのかな？使い方間違ってる？

こっちで聞いた方が詳しく教えてくれると思うが、既存のクラスの機能を拡張するなら違うと思うぞ。
http://pc8.2ch.net/test/read.cgi/tech/1095388499/

>>129
実は仕事で既に動いているPHPプログラム改修作業をすることに
なったのですが、

・非常に見づらいソース。開発者は既に退社＆ドキュメントは無し。
・納期は短いのでリコーディングすることはできない。
・動作自体には問題はなく、現在正常に稼動中。
・機能拡張もあり。

という状況です。ソースが非常に見づらく保守性が著しく低いのと
機能拡張は大幅な仕様変更になるので、できればリコーディングしたい
ところなのですが、納期も無いことですし、何より現在問題なく
稼動中なのでそれはできません。

そこでなるべく既存のクラスに手を加えずに、機能拡張をしたい
という感じです。
このような場合、既存のクラスを継承させた新しいクラスを作り、
動いている部分は利用しつつ、新規の仕様に合わせた設計に作り変える
というやりかたを考えているのですが、これは別にデザインパターンという
わけではなくて、ただのOOPの継承を使ってるだけということですかね。

ちなみに、上記のような場合皆さんならどのような手法を取りますか？
識者のご意見をお聞かせいただけたらと思います。

手法云々以前に、そんなDQNな物を担当させられる事になったら
漏れなら先ず上司に現状を報告し、指示を仰ぐな

1.現状のプログラムが如何に問題点の多い物であるか
2.前任者の無能さを叩き、リコーディングの必要性の訴え
3.リコーディングすれば納期に間に合わせる事は難しい。
　しかし前任者のプログラムに手を入れた場合、（極端に保守性が悪いので）変更によって障害が起きる可能性が高く、納期が大幅に遅れる危険がある。

以上を伝えて今後の方針を決め、増援を求めるなり何なり対策を協議して･･
（要は、「責任逃れの道はちゃんと作っておけよ」と）

>>131
遅レスですが・・・
非常に勉強になりました。

保守

PHPでデザインパターン使ってる？

http://www002.upp.so-net.ne.jp/ys_oota/mdp/Adapter/index.htm

>>6のかわりってこれでいいんじゃね？

良スレだと思うんだけど
みんなデザインパターンってあまり知らないのか？

ムのスレもそうだけで知ってる人ってほんと書かないね

このスレはお題があれば再生するんじゃないの。

良スレだと思うんだけどな。

待ったり進行でいいんｼﾞｬﾏｲｶ？

まあ、とりあえずJ2EEパターンやPoEAに書かれているパターンは抑えるべきだと思うが。
後者の場合、Webは選択肢の一つに過ぎないけど参考になる。
これらをPHPに適用するとどうなるか考えるのも面白い。

このスレ死んでるのか＾＾； 既に語り尽くされてしまっているからなぁ。

全然尽くされてないだろ。
http://www.phparch.com/shop_product.php?itemid=96
とりあえずPHP向けの本が出てるから皆買おう。
そうでなきゃ話しも出来ん。

PHP向けのは要らない

>>143
ペーパーバッグなのにやたら高いね