- 1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ]
- 前すれ
〔隔離〕デザインパターンは本当に必要か？〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/
- 38 名前：33 mailto:sage [2006/03/16(木) 13:11:16 ]
- ＞ 仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。
＞ でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
そうなんだよな〜。
仕事の面白さを取って責任を取るか、仕事の面白さを捨てて責任逃れをするかってとこで、
みんな後者を取っちゃうんだよなぁ。
- 39 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 23:51:12 ]
- なんかごちゃごちゃしてるけど、
結論としてはデザインパターンは設計の話ってことでいいの？
- 40 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:00:51 ]
- どこまでを設計と呼ぶべきかによる、って結論に落ち着くはず。
- 41 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:15:14 ]
- デザインパターンは内部設計の話です
- 42 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:27:53 ]
- やっぱり、設計段階でソースが出てくるのは同考えてもおかしい。
- 43 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:30:59 ]
- こういうフローチャートを書くとこんなソースになるんだよ
っていう教え方はわりとありふれてると思うのです
- 44 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:57:34 ]
- アブストラクトファクトリとシングルトンが
同じ設計レベルで出てくることってあるんかいな？
- 45 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 06:52:58 ]
- >>44
シングルトンを「インスタンスの個数を一定数にする」ものだと考えると
アブストラクトファクトリと同じ設計レベルになる。
もっともシングルトンは「インスタンスの個数を１個にする」という上述した
要求の特殊解なんだが。
- 46 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 06:55:15 ]
- >>42
ヒント： ソースコード＝設計図
つ ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
- 47 名前：34 mailto:sage [2006/03/17(金) 11:25:30 ]
- >>37-38
おー、びっくりした。基本設計で「これは○○パターンが適用できますよ！」とかを売り文句にするのかと思った。
＞これは画面設計書でしょう。 画面設計にいわゆる GoF のデザパタが出てくることは
ここで伝えたかったことはあれです。あれあれ。
「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。
＞関係ないことありませんぜ。 こういった作業はデザパタを適用する上で大きな布石となります。
んー、まぁ、要件によって実装は変わるから、デザパタを適用するか、しないかも確かに変わってくるし、
基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？
- 48 名前：34 mailto:sage [2006/03/17(金) 11:46:10 ]
- >>38
(;´-`)。o(そ、そうか！あいつら責任逃れのためか！あのやろう！)
まあ、そこで責任逃れしても、仕様と違うもの作って、
結局は作り直しさせられて残業の責任を負うはめになると思うけどね。
- 49 名前：33 mailto:sage [2006/03/17(金) 12:40:57 ]
- >>47
＞ ここで伝えたかったことはあれです。あれあれ。
＞ 「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
＞ システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。
悪い。 ここんところの日本語がまったく理解できなかった。
文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
というのは要求定義書の役割であって、画面設計書とは別物という認識なのだが。
基本設計というのは要求定義が完了してから始まる工程であり、そこからデザパタは適用できる
と主張しているわけっす。
＞ 基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？
オブジェクト指向技術を採用して開発を行う、、、となった時点で、変更容易性とかの話しに直結
するのが普通だと思うぞ。
基本設計ってーのは、平たく言えばシステム化対象となる問題領域に境界線を引いていく作業だと
思っている。 その時にどの部分をカプセル化して変更を封じ込められるようにするのかを検討する
ことは当然のことじゃないか？
- 50 名前：34 mailto:sage [2006/03/17(金) 13:33:09 ]
- ＞文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
＞というのは要求定義書の役割であって、
あっ。そりゃそうだ。まあその、手順だね。システム化することによってどんな手順・操作になるかとか。
＞オブジェクト指向技術を採用して開発を行う、となった時点で、変更容易性とかの話しに直結するのが普通だと思うぞ。
ある部分の処理が、将来変更するか否か、柔軟性を持たせるべきか否か、重要度が高いか否か、
それはデザパタや、オブジェクト指向を意識せずに開発を進めた場合でも考慮することじゃないか？
それで内部設計の段階で、ここはこうなる可能性があるから柔軟性を持たせようって話になると思うんだけど。
まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
なんか違う気がする。
- 51 名前：33 mailto:sage [2006/03/17(金) 14:06:42 ]
- >>50
私の頭の中にある基本設計ってーのは、要求定義書が終わってから始まる一連の作業であり，
ユーザーのシナリオを一つ一つ分析しながら、サブシステムに分割していき、最終的には大まか
なクラス設計が完了するところまでと思っています。
で、サブシステムの分割や大まかなクラス設計を行う時点では、洗い出したサブシステムや
クラスの責務を決めないといけないので、この時点でインタフェースに着目する必要があるわけです。
そして、インタフェースという観点で設計を行い始めた時点でデザパタの適用というものは視野に
入っているというのが私の考えです。
＞ まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
＞ なんか違う気がする。
確かにまぁ、「どこかでデザインパターン使えないか？」といった感じで目を皿のようにして探しながら
基本設計するというイメージではなく、インタフェースを主にして考えながら「どういった切り口で
インタフェースを考えたら、うまくまとめられるのか？」といった観点で作業することになる。
しかし、デザパタを知っておくことで考え方の道筋が整理されるから、ここでのヒラメキが得やすくなる
ということが言いたい。
そう言う意味じゃ「デザパタを適用すること」が目的だと言っているのではなく，「デザパタの知識を利用
することでインタフェースを使った考え方ができるようになること」が重要なのだと思っている。
そして、それが基本設計にも適用できると主張している根拠になっているわけ。
- 52 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 20:35:31 ]
- >>51
GoFの23パターンだとそのレベルで適用するのってあったか？
パターンという括りならわかるけど
俺はそのレベルで適用可能なものってデザパタって言葉とずれてると感じるのだが
- 53 名前：33 mailto:sage [2006/03/17(金) 21:03:37 ]
- >>52
おおまかなクラス設計を行うと言っても、頭の中に実現可能性を想い描くことが
できなければ絵に描いた餅になる。 そういった点で GoF の23パターンを見た場合、
適用できないものの方が少ないと思う。
私の場合、よく使うのはBridge、AbstractFactory、Strategy、Observer、Visitor、等々
- 54 名前：52 mailto:sage [2006/03/17(金) 21:18:37 ]
- >>53
なんか俺はちょっと違うことを考えていたらしい
実現可能か考えずに、より適切なモデリングするぐらいのものかと思ってた
言語まである程度意識してるクラス設計まで ってことでいい？
- 55 名前：33 mailto:sage [2006/03/17(金) 21:51:21 ]
- >>54
いいっす。
そもそも、言語を考えずにモデリングするってーのは、はなはだ危険な行為だと思う。
だいたいクラス設計と言った瞬間に、オブジェクト指向言語の採用が前提となってるので
言語を意識しないモデリングなんてあり得ないと思うが。
基本設計時に詳細にとらわれて詳細の海に溺れてしまうのはいけないことだが、詳細に
立ち入ってはいけないということではない。 むしろ詳細を（頭の片隅ででも）考慮すること
なしに作った基本設計など、実現可能性のあやふやなゴミと同じだと思う。 上流工程は
下流工程のことを考えた上でないと成果物を作ってはならないと思っている。
蛇足だが、この辺りのことを理解してないSEが多く、下流工程を意識することなくモデリング
しようとするSEがいるためにSEとPGがいがみ合ってるということもあると思う。
クラス設計時に名詞と動詞を抽出するなんてアプローチを使ってちゃ、下流工程を意識しよう
にも意識できないわな。 そんな設計だと実装時にギャップで苦しむのは目に見えている。
- 56 名前：52 mailto:sage [2006/03/17(金) 22:05:51 ]
- >>55
アナパタは言語意識しないよね あのレベルなのかと思ってた
ソフトウェアを作るためのモデリングじゃなくて、現状把握のためのモデリングかと
基本設計って結構範囲が広いんだな
- 57 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 22:18:08 ]
- 設計段階からデザインパターンを使いまくろうなんて考えていると、
アンチパターンになるぞ。
実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。
- 58 名前：33 mailto:sage [2006/03/17(金) 22:20:45 ]
- アナパタは結構毛色が違うよね。
あれは要求定義書を作る際に使うものだと認識してまふ。
要求定義＝Whatの定義、設計＝Howの定義なのでどうしても切り口は違って
くるかな。
ということで今日はボチボチ帰って寝るわ〜。
- 59 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 00:42:04 ]
- >>57
それ単に設計が不十分なだけじゃん。
- 60 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 01:28:46 ]
- なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい。
- 61 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 03:58:40 ]
- 俺がGoFのデザパタ意識するのは
・(ツールレベルの)フレームワークの設計/実装をしてる時
・実装コードのリファクタリングをする時
だけ。
設計か実装かと言われれば、俺の意識だと実装。
前者は人によっては設計と呼ぶかもしれない。
アプリレベルのフレームワーク設計してる時には
とたとえばJ2EEデザインパターンや
アンチパターンは大いに意識するけど
GoFを意識することはない。
- 62 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 07:55:20 ]
- >>57
＞ 設計段階からデザインパターンを使いまくろうなんて考えていると、
＞ アンチパターンになるぞ。
＞ 実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。
リファクタリング時にデザパタが有用であることは認める。 しかし、設計時にも間違い
なく有効だ。
リファクタリングの時にしかデザパタを使わないという考え方が成立するのは、XPのように
必要最小限のシステムを作った後、各サイクルを1週間程度で回していくというプロセスを
採用した時だけだと思うぞ。 ある程度の大きさのシステムを数ヶ月単位で回していく場合、
その考え方では初回のリファクタリングの作業量が莫大なものとなって破綻してしまう。
それから、アンチパターンについてだが、確かにアンチパターンというものは常に頭に
置いておく必要がある。 しかしアンチパターンのほとんどは「ものごとのバランスをとるため」
に存在するのだ。
「分析地獄」というアンチパターンがあるからといって、分析はやらないでおこう、、、なんて
ことにならないのと同じことだ。
>>60
つ >>46
>>61
アプリレベルの設計でも Bridge パターンはよく使うぞ。
このパターンは、日本で最も過小評価されているパターンなんじゃないかと思う。
俺も「こころ」本を読むまで Bridge を正しく認識していなかったが。w
（他にも当たり前のように Strategy とか使うけど。）
- 63 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 10:44:09 ]
- なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい
- 64 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 10:47:48 ]
- うちだとアプリレベルの設計はもっと大枠で捉えてしまうんすよ。
プロセス・スレッド間の通信には何使うとか、
他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおうとか、
DAO層はあのやり方で実装しようとか、
その程度だけ決めて実装(含むプロトタイプ作成)に入っちゃう。
小規模で言わなくても分かってる同士だからうまく行ってるけど
大規模になったらきちんとフレームワーク設計やらなならんのだろうなぁ、とは感じる。
どうやら「こころ」が良本らしいので読んでみようかな。
- 65 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 12:05:09 ]
- >>64
「プロセス・スレッド間の通信には何使う」や「他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおう」ってーのは、大枠で捉えているという
よりも、「そこにあるものを使う」っていういわばボトムアップの発想じゃないかな。
「DAO層はあのやり方で実装しよう」というのも、レイヤーありきの発想でボトムアップ
に近いと思う。
こういった「あるものを流用」したり「技術からの要求を主」にする設計は、顧客の要求する
ものを取り込むタイミングが難しく、顧客ニーズからブレたものができる危険性がある。
大規模開発をする予定があるのなら、トップダウンの視点は身につけておいた方がいいと
思うぞ。 この視点は小規模開発でも有効だし。
- 66 名前：34 mailto:sage [2006/03/18(土) 13:14:44 ]
- >>51
うーむ、詳細設計をしつつ基本設計をする。って感じに聞こえてしまうなぁ。
基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
それだと俺が働いてきた会社の基本設計とは違うかもしれない。
というか基本設計とかって働いてる場所によって意味合いが変わってくるかもね。
「こころ」か。良本らしいので俺も読んでみようかな。Bridgeはいいパターンだよね。
漏れがよく使うのはDecorator、Bridge、Factory Method、Strategy、Flyweightとか。
他のは理解はできるけど、いい使い所が思いつかなかったりする orz
それぞれのパターンのうまい使い方の情報交換とかしたい。
- 67 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 13:50:37 ]
- こころ たけーよ こころ orz
昨日、本買ったばっかりなのに
- 68 名前：33 mailto:sage [2006/03/18(土) 14:46:19 ]
- >>66
＞ 基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
いや、クラス設計は完了しないっす。 業務オブジェクトのモデリングが主な目的で、
主要なクラスと主要なメソッドだけを記述したクラス図ができるだけです（あっ、パッケージ
関連図も成果物です）。
詳細設計では、さまざまな内部メソッドを追加し、クラスが追加されることも当然あります。
シーケンス図も詳細設計で考えますかね。
＞ それぞれのパターンのうまい使い方の情報交換とかしたい。
いいですねー、それ。 どんな感じでやりゃいいのか、イメージはできてないけど。
- 69 名前：http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 20:16:45 ]
- TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
- 70 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 02:54:15 ]
- 俺は Template Method が一番利用頻度高い。
その次に来るのは Adapter や Decorator、Singleton。
DIコンテナ使うことが殆どなので
潜在的には Factory パターンの利用回数がダントツなんだろうか。
Template Method はDIコンテナと親和性が高いので多用してしまう。
- 71 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 12:36:24 ]
- なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしいよな
- 72 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 17:01:07 ]
- >>71
釣れますか〜？
- 73 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 17:49:49 ]
- >>72
釣られちゃってますね。
- 74 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 19:44:20 ]
- >>73
おっ、釣れた釣れた。
- 75 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 22:21:03 ]
- >>74
これをメタフィッシングパターンと命名する。
- 76 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 01:23:29 ]
- ＞ それぞれのパターンのうまい使い方の情報交換とかしたい。
とか言っちゃったけど、言いだしっぺの俺がまずなんか書かねば…。
- 77 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 21:22:18 ]
- 俺がプロトタイプ作成→リファクタリング→Template Method適用に至るよくある手順
(1) 詳細は無視して大まかな流れだけを実装する。
(2) 細部に肉付けして簡単なテストが通ることを確認する。
(3) 一部の処理が特定の条件下では異なるため、その処理と、条件分岐の部分を書く。
テストが通ることを確認する。
(4) 別の条件だと別の処理を書かなくてはならず、いい加減面倒になってくる。
もっとスマートに書けないものかと思案する。
どう考えても Template Method パターンです。本当にありがとうございました。
(5) という事で書き直す。テストも通る。
- 78 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 22:29:11 ]
- 構造に関するパターンは設計段階でも話が出る可能性はある。
振る舞いに関するパターンはほとんどでない。
- 79 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 08:07:30 ]
- >>77
よくある手順って…おまいは毎回そんなことを考えてるのか。
いい加減、最初からわかれよ。
- 80 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 08:37:57 ]
- >>78
振る舞いに関するパターンでも Command，Interpreter，Observer，Visitor なんかは
大まかな設計レベルでも十分考慮対象だったぞ。 それ以外はちょっと詳細な設計
レベルになるかもしれんが。
あと、生成に関するパターンも構造に関するパターンと対にして設計時点で使うわな。
- 81 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 10:39:52 ]
- >79
最初は動くものを作って、だんだん仕上げてく。
こっちの方が最終的に早く出来上がるし、
変な設計に振り回されないので見通しも良くなる。
別フレームワーク作るわけじゃないんだから。
- 82 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:10:21 ]
- >>81
曳光弾形式の開発ができる現場だとそれもいいんじゃない？
- 83 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:46:40 ]
- 行き当たりばったりなだけじゃん
- 84 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:58:20 ]
- >>83
悪く言えばそうだけど、XPなんて正にそれじゃん。
行き当たりばったりだったとしても、そのプロセスに顧客を巻き込めれば無問題。
スパイラル開発で各サイクルを早く回そうとするのもまったく同じこと。
ただ、そういったプロセスを使えない開発の場合には、まったくもって指摘通りになる。
そしてこの場合、デザパタはリファクタリング時だけでなく、設計時にも活用することになる。
そんだけのことじゃない？
- 85 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 00:43:07 ]
- 俺は84じゃないが、最初は出来るとこまで作って、
後からどんどん洗練してくやり方なんて最近じゃ普通の考え方だと思うんだけど。
むしろ、一気に完成形を目指さず、変更されることを意識しつつ、
少しづつ仕上げていくやり方の方が変更に強いもんができるんじゃないかと。
最近のアジャイル開発とか言われてるのもこんな感じの考え方でしょ？
- 86 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 02:16:46 ]
- 設計する時だってプロトタイプ作成を並行して
頭で考えたことが実際に実現可能か調べながら進めていく。
んで一発で完璧な設計にたどり着くことなんて稀で
いろいろ試行錯誤しながら進めていく。
このプロトタイプ作成作業を実装フェーズにカウントすると
行き当たりばったりだと罵られて、
設計フェーズにカウントするとお咎め無し？
俺には同じものに見える。
- 87 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 08:10:28 ]
- >>86
＞ 俺には同じものに見える。
同じものだ。
しかしプロトタイプを実装フェーズだと考え、それをそのままの形で成果物に
してしまうと成果物が無茶苦茶汚くなることがある。
もちろんそれはプロセス側で対処すべき問題なのだが、そういった対処が
なされていなければ、「行き当たりばったりで作った汚いコード」という謗りを
受けることになる。
プロトタイプを設計フェーズだと考える場合、そのプロトタイプは実装フェーズ
に引き継がれないという暗黙の前提が生まれるため「行き当たりばったり」という
表現は妥当ではなくなる。 ってーか設計フェーズは試行錯誤するのが当たり前。
- 88 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 15:41:57 ]
- なるほど。
- 89 名前：デフォルトの名無しさん mailto:sage [2006/04/07(金) 16:41:51 ]
- このスレではわりと好意的な評価のようなので
こころを買ってみた。
最初は眠くなる話が多い気がする。
良さが分かるまでにしばらくかかりそうだ。
- 90 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:15:39 ]
- >>89
もしや、他にデザパタの本読んだ経験無い？
- 91 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:17:44 ]
- 結城本でFAかと思ってた
- 92 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:21:13 ]
- 結城本はかなりメジャーだからむしろ宣伝するやつが少ない
- 93 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 07:13:58 ]
- 「ここは○×パターンでコーディングする」と書かれた仕様書が上から落ちてくる
のであれば、結城本でも十分だろう。
しかし自分で適用可能なデザインパターンを見つけ出す（＝自分で仕様書を書く）場合、
結城本だけではツライと思う。
（練習問題を飛ばさずに真面目にじっくりやってれば、できるかもしれんが。）
- 94 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 12:47:40 ]
- >90
結城本は持ってる。
デザパタそのものの有用性は自分なりに理解してる。
結城本の感想は93氏に近い。
過程すっ飛ばして天からデザパタが降ってくるスタイル。
パターンの暗記は出来ても理解はありえないなと。
「こころ」は前書き読む限りだと過程を重視してるようなので期待。
まだ第一部読んでるあたりで、UMLがなんちゃらとかそんな話。
非常に眠くなる。読み飛ばせばいいのだけど、それが出来ない性分。
- 95 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 13:08:32 ]
- ある程度パターンを暗記したら、あとは実際にデザパタを意識したコードを読むのが良いと思う。
クラスライブラリを勉強するのがいいかもしれない。
Ｃ＃とかJavaのクラスライブラリリファレンスをみると勉強になったりする。
あとは使ったことないオブジェクト指向言語の勉強するといいかもしれない。RubyとかD言語とか。
後はフレームワークとかも。Log4jとかRailsとか。
論を勉強するのもいいけど、やっぱり証拠もないと理解しにくいかと。
- 96 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 02:30:58 ]
- てっきりあの「あなたの考えを広げるためのヒント」が
結城本の特徴なのかと思ってた。
あれの域にとどまらず、もっと応用の指針について
解説されてる本があるのね。
- 97 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 10:33:45 ]
- 結城本はGOFの劣化版でしかない
GOFのわかりやすいところ(結城が理解できたところ)を
初心者向けに言い直しただけ
それ以上の情報はいっさいなし
オブジェクト指向のこころとアジャイルソフトウェア開発の奥義を読んで、
リファレンスとしてGOFを手元においておけばいいと思う
- 98 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 10:40:03 ]
- GOFはなんでC++を選んだのだろう
- 99 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 11:14:05 ]
- どういうこと？
Smalltalkで全編書けってこと？
GoF本オリジナルは1995年だからJavaはありえんよ
- 100 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 14:18:36 ]
- 日本語版なら付属CDにJavaソースあるしね。
確か、SmalltalkとC++のうち話したいことがわかりやすいほうで例示する、みたいなこと
書いてなかったっけ。
- 101 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 14:21:47 ]
- >>99
単純になんでだろう、と思っただけなんだ。
そうか、Javaなかったのか。そりゃ仕方ない。
- 102 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 15:43:01 ]
- 結城さんに抽象的なモノを説明させるとかなりヤバい。
例とか背景とかなしで、方法だけを詳しく掘り下げる。
同マルチスレッド編もそんなスタイル。途中で読むの止めた。
具体的な内容だとすごく分かりやすい・読みやすいもの書いてくれるんだけど。
HOW TO 本が彼の本来のフィールドだと思う。
- 103 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 01:17:07 ]
- あるシステムのGUIコンポーネントを表示する部分の設計をしているんだけど、
綺麗な設計が浮かばなくて悩んでます。
Componentは0〜複数個のFrameを持っていて、
Frameには0個か1個のComponentが入り、描画の仕方はComponent自身が知っている、
というのが基本設計で、
「WindowコンポーネントはMenuBarフレームとStatusBarフレームを持っている」
「MenuBarフレームにはMenuコンポーネントが入る」
という感じで定義されていく予定なんだけど、
フレームの大きさに合わせて描画するコンポーネントが一般的なのはいいけど、
フレームの中に入ったコンポーネントの大きさによって描画が変化するコンポーネントがあって、
一度の再描画で全部綺麗に更新するためにはトップダウンでもボトムアップでも駄目で困ってます。
こういう場合、どういうパターンが有用だと思いますか？
- 104 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 02:13:37 ]
- Composite
- 105 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 23:20:57 ]
- トップダウンでできんじゃないの？
>>104のいうとおりCompositeで。
- 106 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:12:06 ]
- そういうのはパターンと言うよりアルゴリズムの話
- 108 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:27:37 ]
- >>107
本質的には同じなんだけどな
- 109 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:32:24 ]
- 二回走査しなければいけない原因を分析
アルゴリズムの問題
構造の問題
一回走査で代替するにはどう走査すべきか
新しい手法はどのパターンを適用できるか（できなくても問題ない。銀の弾ではない）
と手順踏めば良いだけのこと
いきなりパターンに解を求めるのは違うよ
- 110 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:36:45 ]
- >>109
108じゃないけど本質的には同じじゃないか ＾＾；
- 111 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:43:37 ]
- 本質は同じだけど、視野が狭くなるでしょ
元の課題の本質が理解できていない人がとるべき行動ではない
- 112 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:53:08 ]
- >>111
そりゃそうだ
- 113 名前：デフォルトの名無しさん mailto:sage [2006/04/17(月) 08:55:15 ]
- まあ、そんなこと言ってると、このスレの視野が狭くなって話題が無くなるけどな
いいじゃん本質は似たようなもんなんだから。そこからパターンの話が広がってくかも試練氏。
- 114 名前：デフォルトの名無しさん mailto:sage [2006/04/18(火) 11:22:22 ]
- そろそろJ2EE5.0パターンとか出てこないものか…と思う。
- 115 名前：デフォルトの名無しさん [2006/05/08(月) 14:39:08 ]
- シングルトンのgetInstanceに引数があるのはおかしいでしょうか。
ファイルを複数管理するクラスで、
アプリ起動時に必要なファイルを読み込み、
メソッドに応じて読み込んだファイルの内容を返すという処理をさせます。
初期化の段階でファイルのルートパスが必要になるので
getInstance(String path)のようなパターンをオーバーロードしようと思っています。
getInstance(String path)はアプリの初期化処理内で1度だけ呼び出し、
ほかはgetInstance()を呼び出すようにしようと考えています。
- 116 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 16:03:28 ]
- >>115
シングルトンって言われると違和感が多少あるけど、処理自体は変じゃないと思いますよ。
- 117 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 18:56:14 ]
- >>115
オレなら初期化用のメソッドを作るかな。
- 118 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 23:54:26 ]
- >115
getInstance(String) の呼び出しを
一回に限定しないとならんわけだけど
それはどのように実現するつもり？
ファイルパスだけでいいのなら、
プロパティファイルなりで指定して
静的初期化ブロックで処理してしまえば良いのでは。
(javaじゃないなら環境変数などで渡す)
- 119 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 09:53:43 ]
- そんなかんじでよさげ。
ハッシュ（マップ）みたいなものにファイルパスをキーにして
自分のインスタンスを複数保持すればいいんでね？
ハッシュから取り出せなかったら場合に、同期で初期化すればよいかと。
- 120 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 11:12:06 ]
- >>116-119
お忙しい中、良レスありがとうございます。
今まではプロパティファイルに絶対パスを指定しておいて初期化メソッドの中で読み込むようなことをしていました。
Webアプリだと環境によってデプロイされる場所が変わってしまい、環境毎にプロパティファイルを設定するのがたいへんでした。
ファイル自体はWEB-INF/fileの位置においてあるので
ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。
- 121 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 15:21:04 ]
- デザパタとは外れますが
＞環境毎にプロパティファイルを設定するのがたいへんでした。
war作るたびに設定編集するのは大変なんで
・環境の数だけ設定ファイルディレクトリ作成
・環境依存の設定ファイルを全てぶちこむ
・環境の数だけwar作成
・warを作成する時には環境に適した設定ファイルを使用する
・warの作成は設定の選択も含めてantで行う。
にしてみてはどうでしょうか。
- 122 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 16:35:08 ]
- >ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。
個人的には
・クラスパス直下に、設定ファイルへのパス一覧を記述した.propertiesファイルを置く。
もしくは
・web.xmlに設定ファイルへパス一覧を記述する。
が好き。
コードがすっきりするよ。
- 123 名前：デフォルトの名無しさん [2006/06/04(日) 02:34:27 ]
- デザインパターン勉強してるんですけど。
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051227/226807/
ここのStateパターンがいまいち理解できません。
if文なんか使いませんと書いてますけど、currentStateを変えるには
結局ifなりswitchなりが必要に思えるんですけど…
どうか教えて下さい！
- 124 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 02:49:21 ]
- if文はあんまりつかいません
と言い換えればOK？
説明文で躓いてるならそれで十分だけど
内容で躓いてるなら
「状態を変更するif文は必要」
「状態を判断するif文は不要」
と考えれば少しは納得いくかも
- 125 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:12:51 ]
- switch(状態){
case 朝:
currentState = mornig;
break;
case 昼:
currentState = day;
break;
case 夜:
currentState = night;
break;
}
currentState.showMessage();
こうしか思いつかないんですけど、なにか根本的に間違ってますか？
- 126 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:18:07 ]
- >>123
意味的な話をすると、State パターンってのは、表示メソッドが showMessage01 〜 showMessage03 まであったときに、
showMessage01────┐ showMessage02────┐ showMessage03────┐
│ 朝表示するメッセージ │ │ 朝表示するメッセージ │ │ 朝表示するメッセージ │
│ 夜表示するメッセージ │ │ 昼表示するメッセージ │ │ 昼表示するメッセージ │
│ 夜表示するメッセージ │ │ 夜表示するメッセージ │ │ 夜表示するメッセージ │
└──────────┘ └──────────┘ └──────────┘
と
朝表示するメッセージ─┐ 夜表示するメッセージ─┐ 夜表示するメッセージ─┐
│ showMessage01 │ │ showMessage01 │ │ showMessage01 │
│ showMessage02 │ │ showMessage02 │ │ showMessage02 │
│ showMessage03 │ │ showMessage03 │ │ showMessage03 │
└─────────┘ └─────────┘ └─────────┘
のどっちが使いやすいかーって話にも関連してくる。ちなみに下が State パターン
- 127 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:19:31 ]
- >>125
違う違う。状態は予めセットしておくの。
んで showMessage したいときに currentState.showMessage()
- 128 名前：123 mailto:sage [2006/06/04(日) 03:33:02 ]
- >>126
なんとなくわかりますが…
>>127
その状態はいつセットするんですか？
123のサイトの説明ではさっぱり。
currentStateには状態がかわった時にmornigなりdayなりがはいるんですよね？
実装がわからないです。
バカでもうしわけないです。
- 129 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:46:21 ]
- >>128
いつセットするか……。
少なくとも showMessage の直前までには正しい状態がセットされてる必要があるね。
逆に考えると、『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
ってのも、メリットの１つじゃないかと。
- 130 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:46:30 ]
- 状態は変わったときだから
その場合は時間が経過した時になるかな？
showMessage()しかないから利点が見え難いかもしれない
朝・昼・夜にできることがshowMessage以外にも10種類あって
Timerで時間がたったときに状態を変更すると考えるといいかも
すると状態変更はTimerの監視部分だけになって
あとはstateを呼ぶだけで勝手に動作が切り替わる
- 131 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:49:00 ]
- 『状態がセット』 というより、『状態を判断するタイミング』 って言ったほうが良いかな。
タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも State パターンで行えるし。
- 132 名前：123 mailto:sage [2006/06/04(日) 03:56:15 ]
- うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の３つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。
- 133 名前：123 mailto:sage [2006/06/04(日) 03:58:09 ]
- >>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。
- 134 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 04:13:05 ]
- >>132
ちなみに、こういうメリットもある。
State パターンってのは、『状態』 と 『その状態のときに行う動作』 を ”１つに” まとめておくから、 (>>126)
currentState.showMessage() するときには、currentState に何がセットされてて、どういう動作を行うのか考える必要はないんよ。
ただ showMessage() すれば、その状態に合った動作が行えるってことは保障されてる。
だから、勝手に MyState のサブクラスを自作して、それを currentState にセットしても動くかもね。
- 135 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:30:10 ]
- たとえば後からStateに夕方を追加したくなったとすると
Stateを使わない方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．showMessageの中のifやswitchに夕方の場合を追加
showMessage以外にも似たメソッドがあったらそれら全ての中のswitch文を更新しなきゃならん。
つまり２の作業があちこちに散らばっていて見落としが起こりがちだし
ちょっと間違えると既存の朝昼夜の動作にもに影響が出かねない。
Stateクラスとしてまとまっている方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．夕方クラスを追加
クラスを増やすぶん、追加すべきコード量自体はむしろStateを使わない場合より多くなりそうだが
２の作業については変更箇所が新規クラスの追加という形で一箇所にまとまっているため
既存の朝昼夜は基本的に触らなくてすむ。
- 136 名前：135 mailto:sage [2006/06/04(日) 21:22:31 ]
- 補足。
状態ではなくメソッドのほうを増やしたくなったとき
Stateを使う場合では朝、昼、夜クラスのメソッドをそれぞれ追加する必要がある。
状態の種別のほうが追加や変更を受けることが多そうならStateを使うといい。
- 137 名前：123 [2006/06/05(月) 11:43:58 ]
- いろいろと説明ありがとうございます。
・朝、昼、夜の状態で行いたい処理が複数ある場合はStateパターンを使う意味がある。
朝、昼、夜クラスとそれらを使うクラスの４つ
夕方が増えた場合の変更箇所 夕方クラス追加。使うクラスの分岐追加の２箇所。
・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
（状態が増える可能性はあるが処理が増える可能性はない。）
朝、昼、夜のshowMessage()メソッド３つ。
スイッチで各showMessage()をよびだす。
夕方が増えた場合の変更箇所 夕方メソッドの追加、スイッチの分岐追加の２箇所。
とゆう認識でよろしいでしょうか？
でもまだ疑問が。
いろいろサイトをみてまわったんだけど、ほとんどの所でStateパターンはifは使わないと書いてます。
でも今までのやり方だと状態を変える時結局ifが必要で、
ただのポリモルフィズムの説明に思えるんですが…
- 138 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:01:57 ]
- >>137
＞・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
割とそうではない場合も。このあたりはケースバイケース。
＞でも今までのやり方だと状態を変える時結局ifが必要で、
>>124
＞ただのポリモルフィズムの説明に思えるんですが…
認識としては全く正しい。多態を使用して、”オブジェクトで状態を表す”のが State パターン
|
 |
