- 1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ]
- 前すれ
〔隔離〕デザインパターンは本当に必要か？〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/
- 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 パターン
- 139 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 13:04:39 ]
- >>137
１．状態を変えるための判断としてのif
２．（今現在の）状態を判断するためのif
がごっちゃになってない？
Stateパターンだとifは使わないというのはおそらく後者のほうかと
前者はどうしようもないよね。
- 140 名前：123 mailto:sage [2006/06/05(月) 13:35:35 ]
- りょうかいです。
すっきりすることができました。これでやっと次に進めます。
ありがとうございました。
- 141 名前：デフォルトの名無しさん [2006/06/06(火) 00:53:15 ]
- >>135
コード量では後者の方がむしろ追加分量が増えるという所が何とも吐き気がするんだが…ｗ
- 142 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:10:57 ]
- インデントとか改行みたいなもんだよ
コードの見通しを良くするために使う。
また、見通しが良くならないのであれば使うべきではない。
- 143 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:18:34 ]
- 一番大事なことは
状態のような概念をオブジェクトとして扱うという考え方
なんじゃないかと思う
- 144 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:04:36 ]
- 一昔前はオブジェクト＝モノ。
モノに操作を与える＝クラス。
だったすからねえ。
ていうかオブジェクト指向のオブジェクトって言葉が
もう時代にそぐわない気すらするですよ。
- 145 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:30:27 ]
- エンティティのほうがまだまし？DBのほうで既成の用語なんで使いづらいけど
- 146 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 20:36:15 ]
- この調子で幸せになれる議論をお願いします
- 147 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 21:52:49 ]
- しかしやっぱ、そんなに議論する内容ってないよねこのスレ。
- 148 名前：デフォルトの名無しさん [2006/07/07(金) 23:17:05 ]
- commandパターンとstateパターンの違いがよく分からん。
commandパターンは、命令をクラス化して、その派生クラス
のexecute()を呼んで処理させる。
stateパターンは、状態をクラス化して、その派生クラスの
hogehoge()とか、fugafuga()を呼んで処理させる。
結局、名前が違うだけで考え方は一緒のような気がするんだ
が・・・という俺の愚痴。
- 149 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:37:55 ]
- >>148
Strategy と State と Command は、どれも多態で処理を切り替えてるから、
おそらく知らない人が見れば同じに見えると思う。
ただ、意味的な物は随分異なる。重点はそこかと。
- 150 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:44:15 ]
- そうかそうか。よーくわかったぞ。
- 151 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 00:42:23 ]
- 考え方は一緒だけど、使う箇所が違うってだけで分けられたパターンって結構あるよね。
前々スレあたりでGoFも一部の似たようなパターンは無くすとかいってなかったっけ？
- 152 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 01:22:41 ]
- >>141
テストケースのコード量も加味して考えるといいのでは。
- 153 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 02:29:05 ]
- StateとStrategyは構造は同じだけど、意味の区別がやや不明瞭。
Commandは意味も構造も違う。
GoFの原典を読むとそんな感じだな。
- 154 名前：デフォルトの名無しさん [2006/07/08(土) 02:58:41 ]
- そんな事いったらChainOfResponsibilityだってたんなるtree構造じゃん
- 155 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 03:20:10 ]
- そうか。なるほど。うん。お前の言いたい事はよくわかったぞ。
- 156 名前：デフォルトの名無しさん [2006/07/08(土) 04:29:30 ]
- 何がtree構造だ？馬鹿。
- 157 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 19:50:03 ]
- どうやるとこのスレ盛り上がるのかな。
- 158 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 22:03:22 ]
- なるほど。GoF信奉者は馬鹿ばっかりだという事がよくわかったぞ。
- 159 名前：デフォルトの名無しさん [2006/07/08(土) 22:04:42 ]
- ごめん。
オレが。
フェブってた。
- 160 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:17:09 ]
- フェブってたという言葉がググレません。
トミーフェブラリーのことかー！
- 161 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:24:07 ]
- ファブってたのtypoじゃないか
- 162 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:30:05 ]
- ファブリーズのことかー！
それは言うならファビョるじゃないかな、たしか。
- 163 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:31:22 ]
- >>162
残念、そこは落とすところだ
- 164 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 01:39:05 ]
- 現在ゲームをつくっていてどういうパターンを使えばいいか悩んでいます
アドバイスをお願いします。
空で変な生き物（まある種の鳥）が動き回るという部分を作っているのですが、
ここで鳥Aと鳥Bはお互いに相手の位置を参照して動きを決めます。
そのため、
空Skyのオブジェクトが鳥A,鳥Bへのオブジェクト参照していて、
同時に鳥Aと鳥BもSkyオブジェクトを参照するというデータ構造にしています。
このようなものを実装するのに適したデザインパターンを教えてください。
- 165 名前：デフォルトの名無しさん [2006/10/21(土) 01:40:01 ]
- age
- 166 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 03:09:11 ]
- >>164
あえて言うなら Mediator
- 167 名前：デフォルトの名無しさん mailto:sage [2006/11/01(水) 21:48:53 ]
- >>164
表示という親クラスを作って
空、鳥Ａ、鳥Ｂをそのメンバにする。
鳥Ａと鳥Ｂの相互作用が絶対に必要なら
Birdsという鳥全体の動きを仕切るクラスを作って、
そこに鳥Ａと鳥Ｂを入れる。
- 168 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:06:17 ]
- >>164
Observer
はどうでしょう。
鳥Aは鳥Bの位置を監視し、その値がかわったら、自分（鳥A）の座標をupdateする。
鳥Bも同様。
- 169 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:11:56 ]
- >>168
無限ループに突入しないようにしないとな
- 170 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 12:34:28 ]
- まだ結城本読了＆自分のプログラムにいくつか採り入れる
っていうレベルで、まだGoFのカタログ読んでないです。
結城本のBridgeの「関連しているパターン」に
AbstractFactoryが載ってるんですけど
引用：
Bridgeパターンに登場するConcreteImplementor役を
環境にあわせて適切に構築するために、
AbstractFactoryパターンが用いられる場合があります
Implementorが「抽象的な工場」、ConcreteImplementorが「具体的な工場」
なのか
ConcreteImplementorが「抽象的な工場」で、それを継承して「具体的な工場」
なのか
状況次第なんですかね？
そろそろGoF読まなきゃと思いつつ、なかなかとっつきにくい
- 171 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 23:07:26 ]
- そもそも
>Bridgeパターンに登場するConcreteImplementor役を
>環境にあわせて適切に構築するために、
構築されるものが ConcreteImplementor なんじゃないの？
- 172 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 10:07:44 ]
- >>171
BridgeパターンのConcreteImplementorが
AbstractFactoryの「抽象的な工場(AbstractFactgory)」を構築するのか
「具体的な工場(ConcreteFactory)」を構築するのか
ということがわからんのです(；´Д`)
- 173 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 21:52:55 ]
- >>172
AbstractFactory パターンを使って、ConcreteImplementor を作る、
だと思うよ。クラス図を書けばすっきりする予感。
- 174 名前：デフォルトの名無しさん mailto:sage [2006/11/22(水) 01:34:32 ]
- >>173
なるほど、そういうことだったんですか。。。
やっと頭の中でクラス図がぼんやりできてきました。
デザパタを教条的に使うだけじゃ、いかんですな。＜自分
ありがとうございます
- 175 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:24:47 ]
- www.01-tec.com/document/cpp_design_pattern.html#Adapter
これってふつうに
class Apple
{
public:
void NamePuts()
{
puts( "りんご" ) ;
}
void ColorPuts()()
{
puts( "赤" ) ;
}
} ;
class Banana
{
public:
void NamePuts()
{
puts( "バナナ" ) ;
}
void ColorPuts()()
{
puts( "黄" ) ;
}
} ;
って書き換えればいいのでは？
- 176 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:39:37 ]
- >>175
書き換えられなかったらどうするのか、って話だ。
- 177 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 16:52:58 ]
- >>175の天才ぶりにびびった。
- 178 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 00:49:44 ]
- void ColorPuts()()
|
 |
