「【GoF】デザインパターン 6

「【GoF】デザインパターン 6 at TECH

1:デフォルトの名無しさん
06/03/09 04:27:58
前すれ

〔隔離〕デザインパターンは本当に必要か？〔スレ〕
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
06/03/09 04:34:12
【神プログラム】
ｽﾚﾘﾝｸ(news4vip板)
にてﾈ申プログラムの実体にせまる！！

>>管理人さんがｽﾊﾟｰﾊｶｰみたいで、画廊のｲﾗｽﾄを無断で持っていくとPCが壊れちゃうらしい。
>>ｺﾜｲﾖｰ(((；･д･)))
>>URLﾘﾝｸ(tenkai-asyu.net)

3:デフォルトの名無しさん
06/03/09 15:27:59
過去スレ
デザインパターンの単純そうな質問 - (1)
ｽﾚﾘﾝｸ(tech板)
【GOF】デザインパターン - (2)
ｽﾚﾘﾝｸ(tech板)
【GoF】デザインパターン 3
ｽﾚﾘﾝｸ(tech板)
【GoF】デザインパターン 4
ｽﾚﾘﾝｸ(tech板)
【GoF】デザインパターン5
ｽﾚﾘﾝｸ(tech板)
〔隔離〕デザインパターンは本当に必要か？〔スレ〕
ｽﾚﾘﾝｸ(tech板)

関連スレ
デザインパターン
URLﾘﾝｸ(piza.2ch.net)
リファクタリング、させてくれ
ｽﾚﾘﾝｸ(tech板)l50
【XP】Agile Process 第2イテレーション【UP】
ｽﾚﾘﾝｸ(tech板)l50
【綺麗】デザインパターンは美しい！【究極の美】＠プログラマー板
ｽﾚﾘﾝｸ(prog板)l50

4:デフォルトの名無しさん
06/03/09 15:28:46
Web Page [ja]
Javaプログラマのためのデザインパターン入門
URLﾘﾝｸ(objectclub.esm.co.jp)
C++で読むデザインパターン
URLﾘﾝｸ(www.01-tec.com)
Javaなページ
URLﾘﾝｸ(home.catv.ne.jp)
デザインパターン入門 (ちとわかりずらい…)
URLﾘﾝｸ(www.netlaputa.ne.jp)
Inversion of Control コンテナと Dependency Injection パターン
URLﾘﾝｸ(www.kakutani.com)
Inversion of Control
URLﾘﾝｸ(wiki.bmedianode.com)
デザインパターンF.A.Q.
URLﾘﾝｸ(www.hyuki.com)
デザインパターンを読み解く
URLﾘﾝｸ(hp.vector.co.jp)
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
URLﾘﾝｸ(www.sra.co.jp)

5:デフォルトの名無しさん
06/03/09 15:29:36
Web Page [en]
Patterns Home Page
URLﾘﾝｸ(hillside.net)
Design pattern (computer science) - Wikipedia, the free encyclopedia
URLﾘﾝｸ(en.wikipedia.org)(computer_science)
C#によるデザインパターン
URLﾘﾝｸ(www.dofactory.com)

6:デフォルトの名無しさん
06/03/09 15:30:23
書籍
オブジェクト指向における再利用のためのデザインパターン
URLﾘﾝｸ(www.amazon.co.jp)
増補改訂版Java言語で学ぶデザインパターン入門
URLﾘﾝｸ(www.hyuki.com)
Java言語で学ぶデザインパターン入門マルチスレッド編
URLﾘﾝｸ(www.hyuki.com)
独習デザインパターン
URLﾘﾝｸ(www.amazon.co.jp)
Javaデザインパターン徹底攻略標準プログラマーズライブラリ
URLﾘﾝｸ(www.amazon.co.jp)
デザインパターンによるJava実践プログラミング
URLﾘﾝｸ(www.amazon.co.jp)
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
URLﾘﾝｸ(www.amazon.co.jp)
J2EEデザインパターン
URLﾘﾝｸ(www.amazon.co.jp)
C#デザインパターン
URLﾘﾝｸ(www.amazon.co.jp)

7:3-6
06/03/09 16:21:29
ういっす。テンプラ貼って見ました。
まったりと語り合いましょうぜ。

8:デフォルトの名無しさん
06/03/09 16:29:42
お姉ちゃん本ってどれ？

9:3-6
06/03/09 16:31:58
>>8
俺も気になります。お姉ちゃんの部分が気になります。

10:デフォルトの名無しさん
06/03/09 19:48:07
お仕着せのパターンで解決できるものばかりなのかね？

11:デフォルトの名無しさん
06/03/09 19:57:21
レゴブロックで作れないものはない

12:デフォルトの名無しさん
06/03/09 20:50:32
23個のオナニーパターン。

13:デフォルトの名無しさん
06/03/09 20:58:10
これ↓人気があるみたいだけど。

デザインパターンとともに学ぶオブジェクト指向のこころ
URLﾘﾝｸ(www.amazon.co.jp)

14:デフォルトの名無しさん
06/03/09 21:33:53
>>8
URLﾘﾝｸ(www.amazon.co.jp)

O・O・P！O・O・P！と連呼すると・・・・

15:デフォルトの名無しさん
06/03/12 02:00:17
結城先生あげ。

16:デフォルトの名無しさん
06/03/12 02:21:34
GoF本読んでSmalltalk好きになった
といっても、GoF本のサンプルってほとんどC++なんだよね
で、SmalltalkでといえばDesign Patterns Smalltalk Companion
マジおすすめ

17:デフォルトの名無しさん
06/03/12 13:58:40
>>16
＞GoF本読んでSmalltalk好きになった
おっ、その心は？
Smalltalkって標準クラスの設計がいいの？

18:デフォルトの名無しさん
06/03/13 00:52:53
『･･･こころ』
買っちゃった
♪明日届く～

19:デフォルトの名無しさん
06/03/13 02:32:32
>>17
そうね～やっぱクラスライブラリの設計ですね
デザインパターンの固まりって感じなんですよ

Smalltalkを調べていくと、言語仕様が非常にシンプルで
言語で規定されるようなこと（制御文とか）すらクラスに
メソッドで定義されている、ってのにちょっと感動。

20:デフォルトの名無しさん
06/03/15 00:05:06
このスレでもよく言われるけどデザインパターンは設計の話じゃないってどういうこと？
あきらかに設計の話だと思うんだけど。

21:デフォルトの名無しさん
06/03/15 00:07:01
実装レベルでしか理解してない奴がまだまだ多いってこった

22:デフォルトの名無しさん
06/03/15 00:23:55
>>20
リファクタリング(この言葉もテストの修正を許容するものから
許容しないものまで幅があって一概には使いにくいな)を前提
にボトムアップで見ると実装の話になる。
テストにしろリファクリングにしろデザパタにしろ、幅がありす
ぎて各自がバラバラの思惑で使うもんだからグダグダになっ
てる。

23:デフォルトの名無しさん
06/03/15 01:28:26
今日、java.io.*のクラス図を初めてjudeで自動生成してみたんだが
・・・いや、美しいな。
（こいつぁArtだ。）
クラス設計とはかくありたいなと思ったよ。

あんまりかっこよかったんで、ついA3で印刷して部屋に貼っといたぜ。

24:デフォルトの名無しさん
06/03/15 01:34:25
>>23
うｐ

25:デフォルトの名無しさん
06/03/15 01:53:19
日頃どういったクラス設計に携わっているかの違いなんだろうか
格段に美しいとは思わない。当たり前の設計だと思うんだが・・・

26:NAME IS NULL
06/03/15 01:57:20
デザパタ入門とＪＡＶＡの格言買ってしまった。
良書ということで一週間読み込むとする。

27:デフォルトの名無しさん
06/03/15 06:29:22
>>20
実装だろ？
じゃなきゃあんなソースばっか載ってる本になるのはおかしい。

28:デフォルトの名無しさん
06/03/15 07:55:55
そもそも実装という作業は、設計作業の一部なんだが。
このことをわかってないﾔｼが多すぎ。

29:デフォルトの名無しさん
06/03/15 09:02:49
設計のデザインパターンと実装のデザインパターンをごっちゃにしてる奴が多いだけでしょ。
デザインパターン＝クラス構造とか思い込むからそうなる。

30:勉強中
06/03/15 10:54:03
設計ってしかことないけど（というかOOPってしたことないけど）、どれをクラスにするのかを決めて、
実装設計でデザパタを使う。実装がうまくいきそうにない（エレガントでないとか）ので、再度クラスを
考え直す。

っていうのを繰り返すのかな？

31:デフォルトの名無しさん
06/03/15 12:36:49
>>20
設計の話だと思うよ。設計というと↓のように大きく分けて２つに分類されると思う。

■設計┬→基本設計
　　　　 └→詳細設計（プログラム設計）

デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
ＳＥレベルでの「基本設計」ではない。

以前、俺も「「設計の話じゃない」みたいなニュアンスで登校したことがあるのでフォロー。
えと、知ってたらごめんなさいごめんなさいごめんなさいなのですが。

32:デフォルトの名無しさん
06/03/15 12:52:11
>>23
java.io.* のクラスは素敵だよな。あの汎用性と拡張性。
いつも通りに入出力処理してるだけで勝手にMD5チェックサムが取れる、
DigestInput/OutputStreamとかもう天才の発想だよな。あれは感動した。

java.io.* は拡張のしやすさから結構、外部の人間が有益なライブラリ作ったりしてるよね。

↓ここの外人のクラス設計も素敵とおもた。ParallelWriterとかSequenceIteratorとか。
URLﾘﾝｸ(www.symbic.net)

33:デフォルトの名無しさん
06/03/15 19:13:01
>>31
＞デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
＞ＳＥレベルでの「基本設計」ではない。

ＳＥという定義をどう捉えているのかは不明だが、保守性を考えたシステムを作ろうと
した場合，基本設計はおろか要求の洗い出しの段階から考慮する必要があるのだが
どうだろうか？
そういった点から考えると、デザパタが詳細設計という枠に収まるかどうかは極めて
疑問だと思うぞ。

P.S.
それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
こと自体が問題を生みだしてるんじゃないか？

34:デフォルトの名無しさん
06/03/16 11:03:32
>>33
まず、基本設計書の認識がお互いあってるか確認したいんだけど、

顧客からの要件を受けて、その要件をコンピュータ上では、
このような形で満たせます。っていう話を顧客に説明するために、
作成する資料が基本設計書という認識でお互いあってるんだよね？

顧客側は一般人だろうし、ただやりたいこと（要件）だけがあるだけで、
それがどんな形でコンピュータ上で実現されるのかわからない。
まずはそれを説明しなくちゃならないんだけど、

それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
実現方式として例えばOSはWINDOWSです。とか
そして、VBのEXE起動して「出勤ボタン」を押しますとか
Accessのファイル開いて「出勤ボタン」を押しますとか
ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか

そんなものだと思うんだけど、そこにデザパタが入っていけるか？

35:34
06/03/16 11:10:17
ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな？
しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
または、その変更になる確立が高い箇所も、デザパタでは吸収できないかもしれないし、
最終的に、それを書くにしても詳細設計書だと思う。

36:34
06/03/16 11:17:07
＞それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
＞こと自体が問題を生みだしてるんじゃないか？
それはあるね。SEしてる人間の連絡不足で、よくPGが仕様とは違うものを作ってしまったりする。
その責任がPGの責任になってしまったりするし。
仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。

でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。

37:33
06/03/16 13:04:26
>>34
それは私の言っている基本設計書ではありません。

＞それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
＞実現方式として例えばOSはWINDOWSです。とか
これは「要求定義書」になりますね。
要求定義書っていうのは顧客の要求だけが書き連ねられているドキュメントではなく、
利害関係者（顧客，投資者，開発チーム等）の一致した要求が書き連ねられるもの
です。　このため OS は Windows で、というのも投資者（開発側企業）の思惑だったり
顧客の要望だったりする。
最近の開発だと、OSの選定が設計扱いされることは少ないんじゃないか？
なお、要求定義書にデザパタが出てくることはまずありません（変更に強いシステムという
要求はあるけど）。

＞そして、VBのEXE起動して「出勤ボタン」を押しますとか
＞ Accessのファイル開いて「出勤ボタン」を押しますとか
＞ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか
これは画面設計書でしょう。　画面設計にいわゆる GoF のデザパタが出てくることは
ありません（芸術的なデザインのパターンはあるでしょうが）。
-----
＞ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな？
＞しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
関係ないことありませんぜ。　こういった作業はデザパタを適用する上で大きな布石となります。

「オブジェクト指向のこころ」に載っている共通性/可変性分析ってーのは、かなり上流工程の
作業になり、こういった行為を通じて構築対象のインタフェースをクローズアップしていくこと
ができます。　ということで、この工程を実施する時点でもうデザパタを意識することになるのです。

38:33
06/03/16 13:11:16
＞仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。
＞でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
そうなんだよな～。
仕事の面白さを取って責任を取るか、仕事の面白さを捨てて責任逃れをするかってとこで、
みんな後者を取っちゃうんだよなぁ。

39:デフォルトの名無しさん
06/03/16 23:51:12
なんかごちゃごちゃしてるけど、
結論としてはデザインパターンは設計の話ってことでいいの？

40:デフォルトの名無しさん
06/03/17 01:00:51
どこまでを設計と呼ぶべきかによる、って結論に落ち着くはず。

41:デフォルトの名無しさん
06/03/17 01:15:14
デザインパターンは内部設計の話です

42:デフォルトの名無しさん
06/03/17 01:27:53
やっぱり、設計段階でソースが出てくるのは同考えてもおかしい。

43:デフォルトの名無しさん
06/03/17 01:30:59
こういうフローチャートを書くとこんなソースになるんだよ
っていう教え方はわりとありふれてると思うのです

44:デフォルトの名無しさん
06/03/17 01:57:34
アブストラクトファクトリとシングルトンが
同じ設計レベルで出てくることってあるんかいな？

45:デフォルトの名無しさん
06/03/17 06:52:58
>>44
シングルトンを「インスタンスの個数を一定数にする」ものだと考えると
アブストラクトファクトリと同じ設計レベルになる。
もっともシングルトンは「インスタンスの個数を１個にする」という上述した
要求の特殊解なんだが。

46:デフォルトの名無しさん
06/03/17 06:55:15
>>42
ヒント：ソースコード＝設計図

つ URLﾘﾝｸ(www.biwa.ne.jp)

47:34
06/03/17 11:25:30
>>37-38
おー、びっくりした。基本設計で「これは○○パターンが適用できますよ！」とかを売り文句にするのかと思った。

＞これは画面設計書でしょう。　画面設計にいわゆる GoF のデザパタが出てくることは
ここで伝えたかったことはあれです。あれあれ。
「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。

＞関係ないことありませんぜ。　こういった作業はデザパタを適用する上で大きな布石となります。
んー、まぁ、要件によって実装は変わるから、デザパタを適用するか、しないかも確かに変わってくるし、
基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？

48:34
06/03/17 11:46:10
>>38
(;´-`)。o(そ、そうか！あいつら責任逃れのためか！あのやろう！)

まあ、そこで責任逃れしても、仕様と違うもの作って、
結局は作り直しさせられて残業の責任を負うはめになると思うけどね。

49:33
06/03/17 12:40:57
>>47
＞ここで伝えたかったことはあれです。あれあれ。
＞「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
＞システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。

悪い。　ここんところの日本語がまったく理解できなかった。
文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
というのは要求定義書の役割であって、画面設計書とは別物という認識なのだが。

基本設計というのは要求定義が完了してから始まる工程であり、そこからデザパタは適用できる
と主張しているわけっす。

＞基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？

オブジェクト指向技術を採用して開発を行う、、、となった時点で、変更容易性とかの話しに直結
するのが普通だと思うぞ。　
基本設計ってーのは、平たく言えばシステム化対象となる問題領域に境界線を引いていく作業だと
思っている。　その時にどの部分をカプセル化して変更を封じ込められるようにするのかを検討する
ことは当然のことじゃないか？

50:34
06/03/17 13:33:09
＞文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
＞というのは要求定義書の役割であって、
あっ。そりゃそうだ。まあその、手順だね。システム化することによってどんな手順・操作になるかとか。

＞オブジェクト指向技術を採用して開発を行う、となった時点で、変更容易性とかの話しに直結するのが普通だと思うぞ。　
ある部分の処理が、将来変更するか否か、柔軟性を持たせるべきか否か、重要度が高いか否か、
それはデザパタや、オブジェクト指向を意識せずに開発を進めた場合でも考慮することじゃないか？
それで内部設計の段階で、ここはこうなる可能性があるから柔軟性を持たせようって話になると思うんだけど。

まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
なんか違う気がする。

51:33
06/03/17 14:06:42
>>50
私の頭の中にある基本設計ってーのは、要求定義書が終わってから始まる一連の作業であり，
ユーザーのシナリオを一つ一つ分析しながら、サブシステムに分割していき、最終的には大まか
なクラス設計が完了するところまでと思っています。

で、サブシステムの分割や大まかなクラス設計を行う時点では、洗い出したサブシステムや
クラスの責務を決めないといけないので、この時点でインタフェースに着目する必要があるわけです。

そして、インタフェースという観点で設計を行い始めた時点でデザパタの適用というものは視野に
入っているというのが私の考えです。

＞まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
＞なんか違う気がする。

確かにまぁ、「どこかでデザインパターン使えないか？」といった感じで目を皿のようにして探しながら
基本設計するというイメージではなく、インタフェースを主にして考えながら「どういった切り口で
インタフェースを考えたら、うまくまとめられるのか？」といった観点で作業することになる。
しかし、デザパタを知っておくことで考え方の道筋が整理されるから、ここでのヒラメキが得やすくなる
ということが言いたい。

そう言う意味じゃ「デザパタを適用すること」が目的だと言っているのではなく，「デザパタの知識を利用
することでインタフェースを使った考え方ができるようになること」が重要なのだと思っている。
そして、それが基本設計にも適用できると主張している根拠になっているわけ。

52:デフォルトの名無しさん
06/03/17 20:35:31
>>51
GoFの23パターンだとそのレベルで適用するのってあったか？
パターンという括りならわかるけど
俺はそのレベルで適用可能なものってデザパタって言葉とずれてると感じるのだが

53:33
06/03/17 21:03:37
>>52
おおまかなクラス設計を行うと言っても、頭の中に実現可能性を想い描くことが
できなければ絵に描いた餅になる。　そういった点で GoF の23パターンを見た場合、
適用できないものの方が少ないと思う。

私の場合、よく使うのはBridge、AbstractFactory、Strategy、Observer、Visitor、等々

54:52
06/03/17 21:18:37
>>53
なんか俺はちょっと違うことを考えていたらしい
実現可能か考えずに、より適切なモデリングするぐらいのものかと思ってた
言語まである程度意識してるクラス設計まで　ってことでいい？

55:33
06/03/17 21:51:21
>>54
いいっす。
そもそも、言語を考えずにモデリングするってーのは、はなはだ危険な行為だと思う。
だいたいクラス設計と言った瞬間に、オブジェクト指向言語の採用が前提となってるので
言語を意識しないモデリングなんてあり得ないと思うが。

基本設計時に詳細にとらわれて詳細の海に溺れてしまうのはいけないことだが、詳細に
立ち入ってはいけないということではない。　むしろ詳細を（頭の片隅ででも）考慮すること
なしに作った基本設計など、実現可能性のあやふやなゴミと同じだと思う。　上流工程は
下流工程のことを考えた上でないと成果物を作ってはならないと思っている。

蛇足だが、この辺りのことを理解してないSEが多く、下流工程を意識することなくモデリング
しようとするSEがいるためにSEとPGがいがみ合ってるということもあると思う。
クラス設計時に名詞と動詞を抽出するなんてアプローチを使ってちゃ、下流工程を意識しよう
にも意識できないわな。　そんな設計だと実装時にギャップで苦しむのは目に見えている。

56:52
06/03/17 22:05:51
>>55
アナパタは言語意識しないよね　あのレベルなのかと思ってた
ソフトウェアを作るためのモデリングじゃなくて、現状把握のためのモデリングかと
基本設計って結構範囲が広いんだな

57:デフォルトの名無しさん
06/03/17 22:18:08
設計段階からデザインパターンを使いまくろうなんて考えていると、
アンチパターンになるぞ。
実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。

58:33
06/03/17 22:20:45
アナパタは結構毛色が違うよね。
あれは要求定義書を作る際に使うものだと認識してまふ。
要求定義＝Whatの定義、設計＝Howの定義なのでどうしても切り口は違って
くるかな。

ということで今日はボチボチ帰って寝るわ～。

59:デフォルトの名無しさん
06/03/18 00:42:04
>>57
それ単に設計が不十分なだけじゃん。

60:デフォルトの名無しさん
06/03/18 01:28:46
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい。

61:デフォルトの名無しさん
06/03/18 03:58:40
俺がGoFのデザパタ意識するのは
・(ツールレベルの)フレームワークの設計/実装をしてる時
・実装コードのリファクタリングをする時
だけ。
設計か実装かと言われれば、俺の意識だと実装。
前者は人によっては設計と呼ぶかもしれない。

アプリレベルのフレームワーク設計してる時には
とたとえばJ2EEデザインパターンや
アンチパターンは大いに意識するけど
GoFを意識することはない。

62:デフォルトの名無しさん
06/03/18 07:55:20
>>57
＞設計段階からデザインパターンを使いまくろうなんて考えていると、
＞アンチパターンになるぞ。
＞実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。

リファクタリング時にデザパタが有用であることは認める。　しかし、設計時にも間違い
なく有効だ。
リファクタリングの時にしかデザパタを使わないという考え方が成立するのは、XPのように
必要最小限のシステムを作った後、各サイクルを1週間程度で回していくというプロセスを
採用した時だけだと思うぞ。　ある程度の大きさのシステムを数ヶ月単位で回していく場合、
その考え方では初回のリファクタリングの作業量が莫大なものとなって破綻してしまう。

それから、アンチパターンについてだが、確かにアンチパターンというものは常に頭に
置いておく必要がある。　しかしアンチパターンのほとんどは「ものごとのバランスをとるため」
に存在するのだ。
　「分析地獄」というアンチパターンがあるからといって、分析はやらないでおこう、、、なんて
ことにならないのと同じことだ。

>>60
つ >>46

>>61
アプリレベルの設計でも Bridge パターンはよく使うぞ。
このパターンは、日本で最も過小評価されているパターンなんじゃないかと思う。
俺も「こころ」本を読むまで Bridge を正しく認識していなかったが。w
（他にも当たり前のように Strategy とか使うけど。）

63:デフォルトの名無しさん
06/03/18 10:44:09
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい

64:デフォルトの名無しさん
06/03/18 10:47:48
うちだとアプリレベルの設計はもっと大枠で捉えてしまうんすよ。
プロセス・スレッド間の通信には何使うとか、
他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおうとか、
DAO層はあのやり方で実装しようとか、
その程度だけ決めて実装(含むプロトタイプ作成)に入っちゃう。

小規模で言わなくても分かってる同士だからうまく行ってるけど
大規模になったらきちんとフレームワーク設計やらなならんのだろうなぁ、とは感じる。

どうやら「こころ」が良本らしいので読んでみようかな。

65:デフォルトの名無しさん
06/03/18 12:05:09
>>64
「プロセス・スレッド間の通信には何使う」や「他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおう」ってーのは、大枠で捉えているという
よりも、「そこにあるものを使う」っていういわばボトムアップの発想じゃないかな。
　「DAO層はあのやり方で実装しよう」というのも、レイヤーありきの発想でボトムアップ
に近いと思う。

こういった「あるものを流用」したり「技術からの要求を主」にする設計は、顧客の要求する
ものを取り込むタイミングが難しく、顧客ニーズからブレたものができる危険性がある。
大規模開発をする予定があるのなら、トップダウンの視点は身につけておいた方がいいと
思うぞ。　　この視点は小規模開発でも有効だし。

66:34
06/03/18 13:14:44
>>51
うーむ、詳細設計をしつつ基本設計をする。って感じに聞こえてしまうなぁ。
基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
それだと俺が働いてきた会社の基本設計とは違うかもしれない。
というか基本設計とかって働いてる場所によって意味合いが変わってくるかもね。

「こころ」か。良本らしいので俺も読んでみようかな。Bridgeはいいパターンだよね。
漏れがよく使うのはDecorator、Bridge、Factory Method、Strategy、Flyweightとか。
他のは理解はできるけど、いい使い所が思いつかなかったりする orz

それぞれのパターンのうまい使い方の情報交換とかしたい。

67:デフォルトの名無しさん
06/03/18 13:50:37
こころたけーよこころ orz
昨日、本買ったばっかりなのに

68:33
06/03/18 14:46:19
>>66
＞基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？

いや、クラス設計は完了しないっす。　　業務オブジェクトのモデリングが主な目的で、
主要なクラスと主要なメソッドだけを記述したクラス図ができるだけです（あっ、パッケージ
関連図も成果物です）。

詳細設計では、さまざまな内部メソッドを追加し、クラスが追加されることも当然あります。
シーケンス図も詳細設計で考えますかね。

＞それぞれのパターンのうまい使い方の情報交換とかしたい。

いいですねー、それ。　　どんな感じでやりゃいいのか、イメージはできてないけど。

69:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:16:45
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

70:デフォルトの名無しさん
06/03/19 02:54:15
俺は Template Method が一番利用頻度高い。
その次に来るのは Adapter や Decorator、Singleton。
DIコンテナ使うことが殆どなので
潜在的には Factory パターンの利用回数がダントツなんだろうか。

Template Method はDIコンテナと親和性が高いので多用してしまう。

71:デフォルトの名無しさん
06/03/19 12:36:24
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしいよな

72:デフォルトの名無しさん
06/03/19 17:01:07
>>71
釣れますか～？

73:デフォルトの名無しさん
06/03/19 17:49:49
>>72
釣られちゃってますね。

74:デフォルトの名無しさん
06/03/19 19:44:20
>>73
おっ、釣れた釣れた。

75:デフォルトの名無しさん
06/03/19 22:21:03
>>74
これをメタフィッシングパターンと命名する。

76:デフォルトの名無しさん
06/03/20 01:23:29
＞それぞれのパターンのうまい使い方の情報交換とかしたい。
とか言っちゃったけど、言いだしっぺの俺がまずなんか書かねば…。

77:デフォルトの名無しさん
06/03/20 21:22:18
俺がプロトタイプ作成→リファクタリング→Template Method適用に至るよくある手順

(1) 詳細は無視して大まかな流れだけを実装する。
(2) 細部に肉付けして簡単なテストが通ることを確認する。
(3) 一部の処理が特定の条件下では異なるため、その処理と、条件分岐の部分を書く。
　　テストが通ることを確認する。
(4) 別の条件だと別の処理を書かなくてはならず、いい加減面倒になってくる。
　　もっとスマートに書けないものかと思案する。
　　どう考えても Template Method パターンです。本当にありがとうございました。
(5) という事で書き直す。テストも通る。

78:デフォルトの名無しさん
06/03/20 22:29:11
構造に関するパターンは設計段階でも話が出る可能性はある。
振る舞いに関するパターンはほとんどでない。

79:デフォルトの名無しさん
06/03/21 08:07:30
>>77
よくある手順って…おまいは毎回そんなことを考えてるのか。
いい加減、最初からわかれよ。

80:デフォルトの名無しさん
06/03/21 08:37:57
>>78
振る舞いに関するパターンでも Command，Interpreter，Observer，Visitor なんかは
大まかな設計レベルでも十分考慮対象だったぞ。　それ以外はちょっと詳細な設計
レベルになるかもしれんが。
あと、生成に関するパターンも構造に関するパターンと対にして設計時点で使うわな。

81:デフォルトの名無しさん
06/03/21 10:39:52
>79
最初は動くものを作って、だんだん仕上げてく。
こっちの方が最終的に早く出来上がるし、
変な設計に振り回されないので見通しも良くなる。

別フレームワーク作るわけじゃないんだから。

82:デフォルトの名無しさん
06/03/21 13:10:21
>>81
曳光弾形式の開発ができる現場だとそれもいいんじゃない？

83:デフォルトの名無しさん
06/03/21 13:46:40
行き当たりばったりなだけじゃん

84:デフォルトの名無しさん
06/03/21 13:58:20
>>83
悪く言えばそうだけど、XPなんて正にそれじゃん。
行き当たりばったりだったとしても、そのプロセスに顧客を巻き込めれば無問題。
スパイラル開発で各サイクルを早く回そうとするのもまったく同じこと。

ただ、そういったプロセスを使えない開発の場合には、まったくもって指摘通りになる。
そしてこの場合、デザパタはリファクタリング時だけでなく、設計時にも活用することになる。
そんだけのことじゃない？

85:デフォルトの名無しさん
06/03/22 00:43:07
俺は84じゃないが、最初は出来るとこまで作って、
後からどんどん洗練してくやり方なんて最近じゃ普通の考え方だと思うんだけど。

むしろ、一気に完成形を目指さず、変更されることを意識しつつ、
少しづつ仕上げていくやり方の方が変更に強いもんができるんじゃないかと。

最近のアジャイル開発とか言われてるのもこんな感じの考え方でしょ？

86:デフォルトの名無しさん
06/03/22 02:16:46
設計する時だってプロトタイプ作成を並行して
頭で考えたことが実際に実現可能か調べながら進めていく。
んで一発で完璧な設計にたどり着くことなんて稀で
いろいろ試行錯誤しながら進めていく。
このプロトタイプ作成作業を実装フェーズにカウントすると
行き当たりばったりだと罵られて、
設計フェーズにカウントするとお咎め無し？

俺には同じものに見える。

87:デフォルトの名無しさん
06/03/22 08:10:28
>>86
＞俺には同じものに見える。
同じものだ。
しかしプロトタイプを実装フェーズだと考え、それをそのままの形で成果物に
してしまうと成果物が無茶苦茶汚くなることがある。
もちろんそれはプロセス側で対処すべき問題なのだが、そういった対処が
なされていなければ、「行き当たりばったりで作った汚いコード」という謗りを
受けることになる。

プロトタイプを設計フェーズだと考える場合、そのプロトタイプは実装フェーズ
に引き継がれないという暗黙の前提が生まれるため「行き当たりばったり」という
表現は妥当ではなくなる。　ってーか設計フェーズは試行錯誤するのが当たり前。

88:デフォルトの名無しさん
06/03/23 15:41:57
なるほど。

89:デフォルトの名無しさん
06/04/07 16:41:51
このスレではわりと好意的な評価のようなので
こころを買ってみた。
最初は眠くなる話が多い気がする。
良さが分かるまでにしばらくかかりそうだ。

90:デフォルトの名無しさん
06/04/08 01:15:39
>>89
もしや、他にデザパタの本読んだ経験無い？

91:デフォルトの名無しさん
06/04/08 01:17:44
結城本でFAかと思ってた

92:デフォルトの名無しさん
06/04/08 01:21:13
結城本はかなりメジャーだからむしろ宣伝するやつが少ない

93:デフォルトの名無しさん
06/04/08 07:13:58
「ここは○×パターンでコーディングする」と書かれた仕様書が上から落ちてくる
のであれば、結城本でも十分だろう。

しかし自分で適用可能なデザインパターンを見つけ出す（＝自分で仕様書を書く）場合、
結城本だけではツライと思う。
（練習問題を飛ばさずに真面目にじっくりやってれば、できるかもしれんが。）

94:デフォルトの名無しさん
06/04/08 12:47:40
>90
結城本は持ってる。
デザパタそのものの有用性は自分なりに理解してる。

結城本の感想は93氏に近い。
過程すっ飛ばして天からデザパタが降ってくるスタイル。
パターンの暗記は出来ても理解はありえないなと。

「こころ」は前書き読む限りだと過程を重視してるようなので期待。
まだ第一部読んでるあたりで、UMLがなんちゃらとかそんな話。
非常に眠くなる。読み飛ばせばいいのだけど、それが出来ない性分。

95:デフォルトの名無しさん
06/04/08 13:08:32
ある程度パターンを暗記したら、あとは実際にデザパタを意識したコードを読むのが良いと思う。

クラスライブラリを勉強するのがいいかもしれない。
Ｃ＃とかJavaのクラスライブラリリファレンスをみると勉強になったりする。

あとは使ったことないオブジェクト指向言語の勉強するといいかもしれない。RubyとかD言語とか。
後はフレームワークとかも。Log4jとかRailsとか。

論を勉強するのもいいけど、やっぱり証拠もないと理解しにくいかと。

96:デフォルトの名無しさん
06/04/09 02:30:58
てっきりあの「あなたの考えを広げるためのヒント」が
結城本の特徴なのかと思ってた。
あれの域にとどまらず、もっと応用の指針について
解説されてる本があるのね。

97:デフォルトの名無しさん
06/04/09 10:33:45
結城本はGOFの劣化版でしかない
GOFのわかりやすいところ(結城が理解できたところ)を
初心者向けに言い直しただけ
それ以上の情報はいっさいなし

オブジェクト指向のこころとアジャイルソフトウェア開発の奥義を読んで、
リファレンスとしてGOFを手元においておけばいいと思う

98:デフォルトの名無しさん
06/04/09 10:40:03
GOFはなんでC++を選んだのだろう

99:デフォルトの名無しさん
06/04/09 11:14:05
どういうこと？
Smalltalkで全編書けってこと？
GoF本オリジナルは1995年だからJavaはありえんよ

100:デフォルトの名無しさん
06/04/09 14:18:36
日本語版なら付属CDにJavaソースあるしね。
確か、SmalltalkとC++のうち話したいことがわかりやすいほうで例示する、みたいなこと
書いてなかったっけ。

101:デフォルトの名無しさん
06/04/09 14:21:47
>>99
単純になんでだろう、と思っただけなんだ。
そうか、Javaなかったのか。そりゃ仕方ない。

102:デフォルトの名無しさん
06/04/09 15:43:01
結城さんに抽象的なモノを説明させるとかなりヤバい。
例とか背景とかなしで、方法だけを詳しく掘り下げる。
同マルチスレッド編もそんなスタイル。途中で読むの止めた。

具体的な内容だとすごく分かりやすい・読みやすいもの書いてくれるんだけど。
HOW TO 本が彼の本来のフィールドだと思う。

103:デフォルトの名無しさん
06/04/13 01:17:07
あるシステムのGUIコンポーネントを表示する部分の設計をしているんだけど、
綺麗な設計が浮かばなくて悩んでます。

Componentは0～複数個のFrameを持っていて、
Frameには0個か1個のComponentが入り、描画の仕方はComponent自身が知っている、
というのが基本設計で、
「WindowコンポーネントはMenuBarフレームとStatusBarフレームを持っている」
「MenuBarフレームにはMenuコンポーネントが入る」
という感じで定義されていく予定なんだけど、

フレームの大きさに合わせて描画するコンポーネントが一般的なのはいいけど、
フレームの中に入ったコンポーネントの大きさによって描画が変化するコンポーネントがあって、
一度の再描画で全部綺麗に更新するためにはトップダウンでもボトムアップでも駄目で困ってます。

こういう場合、どういうパターンが有用だと思いますか？

104:デフォルトの名無しさん
06/04/13 02:13:37
Composite

105:デフォルトの名無しさん
06/04/13 23:20:57
トップダウンでできんじゃないの？
>>104のいうとおりCompositeで。

106:デフォルトの名無しさん
06/04/13 23:34:25
トップダウンだと、例えばWindowコンポーネントがMenuコンポーネントを中に持つとき、

1.
Windowコンポーネントが自分自身の高さ、幅を持つ（例；width=640 height=400）
Menuコンポーネントが入るべきフレームを設定する（フレームの大きさは幅640、高さ不定）

2.
MenuコンポーネントはWindowコンポーネントの幅に応じて高さが決まる
（幅が狭いとメニューが二行になったりする。今回は30pxと決定）

3.
WindowコンポーネントはMenuコンポーネントのすぐ下にToolBarコンポーネントが入るフレームを設定する。
この位置は、Menuコンポーネントが自分自身の位置を決めることによって初めて決まる。

今回のようにこの順番で描画してくれるなら問題ないのですが、
例えばToolBarが先に初期化されるようにプログラマに記述されたら、そのタイミングではToolBarを置く位置がわからなくなります。
二回走査すればいいのでしょうが、今ひとつすっきりとしなくて困っていますが、
とりあえずCompositeで書いてみるかな…

107:デフォルトの名無しさん
06/04/14 08:12:06
そういうのはパターンと言うよりアルゴリズムの話

108:デフォルトの名無しさん
06/04/14 08:27:37
>>107
本質的には同じなんだけどな

109:デフォルトの名無しさん
06/04/14 08:32:24
二回走査しなければいけない原因を分析
　アルゴリズムの問題
　構造の問題

一回走査で代替するにはどう走査すべきか

新しい手法はどのパターンを適用できるか（できなくても問題ない。銀の弾ではない）

と手順踏めば良いだけのこと
いきなりパターンに解を求めるのは違うよ

110:デフォルトの名無しさん
06/04/14 08:36:45
>>109
108じゃないけど本質的には同じじゃないか　＾＾；

111:デフォルトの名無しさん
06/04/14 08:43:37
本質は同じだけど、視野が狭くなるでしょ
元の課題の本質が理解できていない人がとるべき行動ではない

112:デフォルトの名無しさん
06/04/14 08:53:08
>>111
そりゃそうだ

113:デフォルトの名無しさん
06/04/17 08:55:15
まあ、そんなこと言ってると、このスレの視野が狭くなって話題が無くなるけどな
いいじゃん本質は似たようなもんなんだから。そこからパターンの話が広がってくかも試練氏。

114:デフォルトの名無しさん
06/04/18 11:22:22
そろそろJ2EE5.0パターンとか出てこないものか…と思う。

115:デフォルトの名無しさん
06/05/08 14:39:08
シングルトンのgetInstanceに引数があるのはおかしいでしょうか。

ファイルを複数管理するクラスで、
アプリ起動時に必要なファイルを読み込み、
メソッドに応じて読み込んだファイルの内容を返すという処理をさせます。

初期化の段階でファイルのルートパスが必要になるので
getInstance(String path)のようなパターンをオーバーロードしようと思っています。

getInstance(String path)はアプリの初期化処理内で1度だけ呼び出し、
ほかはgetInstance()を呼び出すようにしようと考えています。

116:デフォルトの名無しさん
06/05/08 16:03:28
>>115
シングルトンって言われると違和感が多少あるけど、処理自体は変じゃないと思いますよ。

117:デフォルトの名無しさん
06/05/08 18:56:14
>>115
オレなら初期化用のメソッドを作るかな。

118:デフォルトの名無しさん
06/05/08 23:54:26
>115
getInstance(String) の呼び出しを
一回に限定しないとならんわけだけど
それはどのように実現するつもり？

ファイルパスだけでいいのなら、
プロパティファイルなりで指定して
静的初期化ブロックで処理してしまえば良いのでは。
(javaじゃないなら環境変数などで渡す)

119:デフォルトの名無しさん
06/05/09 09:53:43
そんなかんじでよさげ。

ハッシュ（マップ）みたいなものにファイルパスをキーにして
自分のインスタンスを複数保持すればいいんでね？
ハッシュから取り出せなかったら場合に、同期で初期化すればよいかと。

120:デフォルトの名無しさん
06/05/09 11:12:06
>>116-119
お忙しい中、良レスありがとうございます。
今まではプロパティファイルに絶対パスを指定しておいて初期化メソッドの中で読み込むようなことをしていました。

Webアプリだと環境によってデプロイされる場所が変わってしまい、環境毎にプロパティファイルを設定するのがたいへんでした。
ファイル自体はWEB-INF/fileの位置においてあるので
ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。

121:デフォルトの名無しさん
06/05/09 15:21:04
デザパタとは外れますが
＞環境毎にプロパティファイルを設定するのがたいへんでした。
war作るたびに設定編集するのは大変なんで
・環境の数だけ設定ファイルディレクトリ作成
・環境依存の設定ファイルを全てぶちこむ
・環境の数だけwar作成
・warを作成する時には環境に適した設定ファイルを使用する
・warの作成は設定の選択も含めてantで行う。
にしてみてはどうでしょうか。

122:デフォルトの名無しさん
06/05/09 16:35:08
>ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。

個人的には
・クラスパス直下に、設定ファイルへのパス一覧を記述した.propertiesファイルを置く。
もしくは
・web.xmlに設定ファイルへパス一覧を記述する。
が好き。

コードがすっきりするよ。

123:デフォルトの名無しさん
06/06/04 02:34:27
デザインパターン勉強してるんですけど。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
ここのStateパターンがいまいち理解できません。
if文なんか使いませんと書いてますけど、currentStateを変えるには
結局ifなりswitchなりが必要に思えるんですけど…
どうか教えて下さい！

124:デフォルトの名無しさん
06/06/04 02:49:21
if文はあんまりつかいません
と言い換えればOK？

説明文で躓いてるならそれで十分だけど
内容で躓いてるなら
「状態を変更するif文は必要」
「状態を判断するif文は不要」
と考えれば少しは納得いくかも

125:デフォルトの名無しさん
06/06/04 03:12:51
switch(状態){
case 朝:
currentState = mornig;
break;
case 昼:
currentState = day;
break;
case 夜:
currentState = night;
break;
}
currentState.showMessage();

こうしか思いつかないんですけど、なにか根本的に間違ってますか？

126:デフォルトの名無しさん
06/06/04 03:18:07
>>123
意味的な話をすると、State　パターンってのは、表示メソッドが　showMessage01　～　showMessage03　まであったときに、

showMessage01──┐　showMessage02──┐　showMessage03──┐
│　朝表示するメッセージ　│　│　朝表示するメッセージ　│　│　朝表示するメッセージ　│
│　夜表示するメッセージ　│　│　昼表示するメッセージ　│　│　昼表示するメッセージ　│
│　夜表示するメッセージ　│　│　夜表示するメッセージ　│　│　夜表示するメッセージ　│
└─────┘　└─────┘　└─────┘

と

朝表示するメッセージ─┐　夜表示するメッセージ─┐　夜表示するメッセージ─┐
│　showMessage01　　│　│　showMessage01　　│　│　showMessage01　　│
│　showMessage02　　│　│　showMessage02　　│　│　showMessage02　　│
│　showMessage03　　│　│　showMessage03　　│　│　showMessage03　　│
└─────┘　└─────┘　└─────┘

のどっちが使いやすいかーって話にも関連してくる。ちなみに下が　State　パターン

127:デフォルトの名無しさん
06/06/04 03:19:31
>>125
違う違う。状態は予めセットしておくの。
んで　showMessage　したいときに　currentState.showMessage()

128:123
06/06/04 03:33:02
>>126
なんとなくわかりますが…
>>127
その状態はいつセットするんですか？
123のサイトの説明ではさっぱり。
currentStateには状態がかわった時にmornigなりdayなりがはいるんですよね？
実装がわからないです。
バカでもうしわけないです。

129:デフォルトの名無しさん
06/06/04 03:46:21
>>128
いつセットするか……。
少なくとも　showMessage　の直前までには正しい状態がセットされてる必要があるね。

逆に考えると、『状態がセット』　されるタイミングと　『　実際に　showMessage　』　されるタイミングを離すことが出来る
ってのも、メリットの１つじゃないかと。

130:デフォルトの名無しさん
06/06/04 03:46:30
状態は変わったときだから
その場合は時間が経過した時になるかな？

showMessage()しかないから利点が見え難いかもしれない
朝・昼・夜にできることがshowMessage以外にも10種類あって
Timerで時間がたったときに状態を変更すると考えるといいかも

すると状態変更はTimerの監視部分だけになって
あとはstateを呼ぶだけで勝手に動作が切り替わる

131:デフォルトの名無しさん
06/06/04 03:49:00
『状態がセット』　というより、『状態を判断するタイミング』　って言ったほうが良いかな。

タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも　State　パターンで行えるし。

132:123
06/06/04 03:56:15
うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の３つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』されるタイミングと『実際に showMessage 』されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。

133:123
06/06/04 03:58:09
>>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。

134:デフォルトの名無しさん
06/06/04 04:13:05
>>132
ちなみに、こういうメリットもある。

State　パターンってのは、『状態』　と　『その状態のときに行う動作』　を　”１つに”　まとめておくから、　(>>126)
currentState.showMessage()　するときには、currentState　に何がセットされてて、どういう動作を行うのか考える必要はないんよ。
ただ　showMessage()　すれば、その状態に合った動作が行えるってことは保障されてる。

だから、勝手に　MyState　のサブクラスを自作して、それを　currentState　にセットしても動くかもね。

次ページ