デザインパターンの単純そうな質問

結局のところ、デサパタは個々のパターン自体を学ぶ為のものではなく、
各々のパターンに公共で通用する名前をつけて、プログラマ同士の
円滑なコミュニケーションを図る為のものだろ。

それがいつの間にか、個々のパターン自体を知らない初心者の為の教科書として
使われるようになってしまったというだけの話。

広辞苑を読むだけで、言葉の達人になれる訳がない。様々な文章を読み、
その言葉が使用される文脈を肌で理解する作業を怠っていながら、
聞きかじりの知識で使い慣れない難しい言葉をこれ見よがしに使ったところで、
本当にその言葉の意味を知った人から嘲われる(←なぜかへんかんできない)だけだ。

広辞苑のメタファは不適切かと。それは、言語の規格書に似てる。
色々な言語によるお芝居を分析し、共通のシークエンスを抽出した文化人類学の文献とかに、
デザパタは似てる。（そんな研究があったのかは知らないが。）

そこにあるシークエンスたちは、読者に創造力さえあれば、
単独で感動を与えることすらあるのさ。

言いたいことは分かるが、漏れと>>953 の間には
「言葉」というものについての思い入れの差があるな。
ちょっと反論。

>共通のシークエンスを抽出した文化人類学の文献とかに、
>デザパタは似てる。

抽出された概念は時を経るごとに巷間に伝わり、ついには
広辞苑に載るようになる。じつは辞書に載っている単語は全て、
そのような歴史の積み重ねによって作られてきたものばかりだ。

そして（ここが重要だが）辞書は決して言葉について「定義」はしない。
もともと出来ないのだ。
出来ることといえば、その言葉のイメージを連想させる読者の経験を
思い起こさせる言葉を列記することだけだ。

メタ文化人類学の話はさておいて。
パターン一種類しか使わないって、あんまない。
・MediatorとObserverでGUIのアーキテクチャ、とか、
・MethodFactoryとSingletonでMetaObjectの代り、とか、
・TemplateMethodとStrategyでルールの山を整理、とか、
合わせ技で使うのが普通でしょ。(最後の例は、Ruleエンジン使いたいと思ってるけど)

そーゆー、組合わさってナンボのパターンを、一個一個切り離して、
組み合わせの妙を探索したり、
パターン間の相互作用を分析しようとしたのが、
GoF本の面白い所。但し、「関連するパターン」の掘り下げが足りないような気がする。

＃そろそろアナパタ読み進めないと、ヤバいな・・・。

>>952
それは違うよ。
他の人のソース読みこなし、自分のソースを洗練する訓練して無い人は、
やっぱ頭で判ってるつもりでも、とんでもないソース書いちゃうもんだよ。
経験して覚えろ。失敗から学べ。最初から複雑なパターンを使おうとせず、
シンプルなコードをリファクタリングで洗練する練習をすべきだ。

あと、「デザパタが簡単過ぎる」などと底が浅そうな発言してる暇あったら、
もっといろいろなパターンを勉強されてはいかが？

>>951
そ、そんな感じ。
自分で発見したパターンは、なかなか忘れないもんだけど、
人から聞いて覚えたパターンてのは、なかなか血肉にならないもんだ。

>>955
>それは違うよ。
？？？

まず、>>952 が何を言わんとしているのか
（というより >>955 による解釈だな）、
そして何処がどう違うのかを要約してくれないか？

一体 >>952 の何処から「デザパタが簡単過ぎる」
という珍説が導出されたのか知りたいものだ。

>>955
>>956
どういうソースを読みまくるのが良いのでしょうか？
実例を出してもらえると参考になりまつ。

話の本筋が見えていないおかしな人(>>９５8)はｽﾙｰしとくとして。

>>959
SqueakのSmalltalkコード、
J2SEやらJ2EEのプロダクション・コード、
OO関係ないけど、*BSDやオプソ・サーバ類のコード、
ってあたりは、デフォルトでしょ。
あと、VC++ベースやMacOS Xのフリーウェア、言語処理系、Linux, GNU
なんてのにも目を通すと、
視点や趣味が違うと、ソースがかくも変わるのか、なんて視点が広がるよね

いや、まあ間違っちゃいないが、
GoFの本とOOパターン修得の話をしていた気がするのだが。。。

961
え、何か？
まるっきりスタンダードな、パターン学ぶ方法の話だけど。

>>961みたいな発言する方って、ナニ様なんでしょう・・・♥
きっと、Dr.Gammaかなｗ
じゃ、ET++ にも目を通せｗ

実例、っつってんだから、
あなたが読んで感銘を受けたコードを教えてあげれば？

きみ、失敬だな。
君自身の体験を語ってやれば良いでしょ。

俺の場合、DigitalkのSmalltalk/Vコードと、Minixコードと、DOSベースのマルチタスクカーネル、
あと 1990年以前にリリースされたほとんど全てのオプソ・言語処理系、が原点かな。
言語処理系のソースは、結構いろいろなパターンが使われていて、おもしろい

*BSDとか、OO＆制約ベースの toolkitとか、Lisp言語処理系に嵌ってた時期もあったな。

失敬なきみは、ナニのソースに感銘を受けたの？

あら、日本語が読めないのね。
ごめんな。

また、頭の調子が悪い人にﾏｼﾞﾚｽしちまったｗ

しっかし、夜の一時に、俺の帰宅待ち構えていたように絡んでくるあんた、暇＆悲惨だな。
そんなに暇なら、Squeakの全ソース (Smalltalkコード部分)でも読んで、パターン抽出でもしてみたらｗ

で、そういう長い経験がない人が、会社入って PG してくれというときに、
どうやって勉強すればよいのでしょうか？

ぷ〜でもしながら、そ〜す読めばぁ？

>>971
経験がなければ理論先行で頭に詰め込んでけばいいよ。
で、実際似たようなパターンに遭遇した・設計した場合にこんなもんかと
復習しながらデザパタの知識とのすりあわせをしていく。
で、さりげなく会社でデザパタ用語を撒き餌しながら同志を募っていくと。

ともかく言語の文法やその言語によるOOの手法ほど即効性はないから
最初は知識として持っておけばいいと思うよ。
実践におけるパターン認識能力は間違いなく高まるからさ。

ただお勉強の順番としては
文法、OO、UML、(中略)、、、、デザパタ
って気がするけどね。

デザパタ本は一回読んだだけでは無意味で
コーディングをしつつ何度も読まないと身につかないでしょ。
実践と理論を行き来することで体感するしかないと思いますよ。

いや、一回読めばすぐ身に付くよ
「あったあったそういう事」というような基本的なのばかりだから

＞975
それはもう既に実践経験を積んでる、ということでしょ？
実践経験がないと読んでも理解は半分で終わります。

C++関係で良いソースないですかね？
JavaやSmalltalkには定番があるんだけど、C++にはあんまり見当たらないし、
上でも例が上がってないね。
CppUnitぐらいしか読んでない。

>976
じゃあソース書いて実践経験をつければいいのに

>>978
もとからそう言ってるやん。
読んで書いて書いて読んで。習うより慣れろ、と。
普通すぎる。。。

　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　次スレまだ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　 愛媛みかん　 |／

FactoryMethodがわからない･･･
ConcreteProductごとに対応するConcreteCreatorを作るんだよね。
素直にConcreteProductをnewすればよさそうに思えてならない･･･
このパターンの意味ってなんですか？
どんなメリットがあるのでしょうか？

>>981
1対1ではなく、複数の種類の ConcreteProduct を作成する場合には意味がある。
「Productのセット」を切り替えるわけ。
この辺、デザパタの教科書には必ず書いてあるぞ。

所詮プログラム
お前らソフト屋はこんな本読んでる暇あったらとっととコーディングしろ。
こんなことに時間と頭使うな。
どうせ使い捨てのカスなんだよ。おめぇら。

>>983
捨てられるまでは使われるからな。

>>981
使い道は２つ。
一つは、Ｂａｓｅクラスに*static*なFactoryMethodを定義して、その中で
必要なConcreteProductを生成するという方法。
拡張性がなくてカコ悪いが、サブクラスが固定的な場合は有効。
もう一つは、すでにあるインスタンスから、新しいインスタンスを生成するような、
Prototype的な使い方。Prototypeは、属性を引き継ぐが、FactoryMethodは、
属性を引き継がないくらいの違い。仮想コンストラクタと呼ばれる所以。

>>981
デザインパターンを勉強するときは、パターンごとに１つでいいから具体例を覚えるといい

例えば今、ＷｉｎかＭａｃかで分岐するコードがあったとする

if (state == win) {
/* win の場合 なんたらかんたら。。*/
} else if (state == mac) {
/*mac の場合 なんたらかんたら。。*/}

毎回こんなコードを書くよりなら、２つをサブクラスにしたほうがスマート

// ----------< 生成 >--------------
OSClass os;
if (state == win) { os = new win()
} else if (state == mac) { os = new mac()
}
// -------< 生成終わり >--------

os.operation();

この、生成部分もクラスに持たせれば、工場パターンの出来上がり。

OSClass os = OSClass.create( state );
// OSClassがstateを知っているなら create()だけでいい
os.operation();

Commandパターンについてなんですが
Invokerの意味がわかりません。
大概のサンプルソースは

CliantがCommandを生成して
Invokerに渡してInvokerが実行

という感じみたいですが
CliantがCommandを生成してる時点でそのままCliantが呼んでも
あんま変わらないような気がするんですが・・・

デザインパターンの骸骨たちって既出？

>>987
クライアントがInvoker使うのなら、そうだろうな。。とだけ、言っておこう

>>981>>987
必要性がないならシンプルな方法で組んだほうがよい
なんでもかんでもデザパタを適用すればいいってものではない
修正の影響範囲を最小限に抑えるという原則に従っていけば
そこに必要性があればデザパタの各クラスの役割も見えてくる
面倒なだけだと思えるのなら必要性がないということ

自分の書いたコードを仕様から修正・拡張しながらリファクタリングしていけば
勉強になるんじゃないかな
サンプルだけで覚えても使える勉強にはならんよ

>>988
>デザインパターンの骸骨たちって既出？
あそこはわかりやすいから、漏れもよく見るよ
で、６で既出だな。

>>991
ども

次ぎすれどこ？

>987
Invokerは、実行キューだと思えばいい。
例えば、サーバーシステムを考えてみる。
サーバーでグラフを出力するような重い処理をしているときに、なにも
考えずに、グラフ出力用の同期関数を呼ぶと、グラフ出力処理をしている
間、他のクライアントはなにもできなくなってしまう。（ブロックされる）
そこで、グラフ処理をスレッド化して、要求をキューに蓄積すれば他の
クライアントの要求をいったん受けて、あとで処理するようなことができる。
COMMANDは、ＧＯＦ本で紹介されているようにマクロのようなバッチ的な
使い方もできるし、高度なフレームワークを構築することもできる幅の広い
パターンなので、もう少し経験を積んでからチャレンジしたほうがよいだろう。

>>980

次スレ
http://pc5.2ch.net/test/read.cgi/tech/1065535118/l50

997

998

999GET!!

多分無理っぽいけど1000ゲット

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。