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

1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ] 前すれ 〔隔離〕デザインパターンは本当に必要か？〔スレ〕 pc8.2ch.net/test/read.cgi/tech/1119348596/ 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()() 179 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 10:45:59 ] >>175 あなた程の天才がなぜこんなスレを見てるのですか 180 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 11:56:28 ] Adaptor　-　貴方は委譲しますか？継承しますか？ 漏れは原則委譲派 181 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 20:42:59 ] >>180 case by case だけど、俺は継承だな…… 182 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 23:47:27 ] 委譲(包含+転送)しか使ったことないです。 継承の方が優れてるケースってどんな時でしょうか。 基本的に adapter is a adaptee な状態にはならんので 継承使おうと言う気が起きないです。 183 名前：181 mailto:sage [2006/11/29(水) 01:17:07 ] あ、ごめん。普通に勘違いした。委譲だ委譲。 よく考えなくとも Adapter クラスを継承することは大前提なんだよな。 すまね orz 184 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 04:55:44 ] 結局継承によるアダプターは誰も実践してない罠。 でもアダプターパターンの解説見てると 継承による方法が先の場合が多いのはなぜなんだぜ。 185 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 09:15:54 ] 委譲よりも継承の方が、初心者にはOOっぽく見えるんだぜ？ 186 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 23:52:47 ] 継承による場合は override によって処理を上書きすることで 完全にコントロール出来ることが利点だと説明するサイトがあったが コントロールしちゃったらアダプタでもなんでもないと思った。 187 名前：デフォルトの名無しさん [2006/12/28(木) 20:59:47 ] 質問なんですが、ファクトリパターンってインスタンスが一つあればいいってのはわかるんですが、 メソッドをstaticじゃなくて、シングルトンパターンにする必要があるのですか？ どうせなら、インスタンス作らないで、staticメソッドにしてアクセスした方がいい気がするのですが インスタンスを生成するかstaticにアクセスするかどちらの方がいいのですか？ 188 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:06:43 ] 一概には言えまい staticにしてしまうとファクトリ事態を抽象化することが出来んからな 189 名前：デフォルトの名無しさん [2006/12/29(金) 00:46:41 ] >>188 なるほど 190 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:52:45 ] >>182 adapter has a adaptee？ 191 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:58:56 ] client　→　Target 　　　　　　　　△ 　　　　　　　　 | 　　　　　　　Adapter→Adaptee TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは？ AdapterはAdapteeに委譲するのは当然だし 192 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 06:29:05 ] >>191 当然だと思う。 でも世のデザパタ解説サイトだと 「継承」「委譲」の2種類を例として出してる場合、 「継承」ではTargetはクラス、Adapterはそれを継承する形になってて 「委譲」ではTargetはインターフェース、Adapterはそれを実装する形になってる。 本質を考えれば継承の場合でもTargetはインターフェースだろ？と思うんだけど。 (というか継承はいらねえと思われ。) オリジナルのGoF本を読んでないので分からんけど。 193 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:14:40 ] >>192 クラスでもいいのでは？ Targetとしての振る舞いに共通なものがあるのだとしたら 抽象クラスとする事もアリだと思うけど Client　→　Target 　　　　 　　　　△ 　　　　　　　　　; 　　　　　　AbstractTarget　 　　　　　　　　　△　　　　　　 　　　　　　　　　 |　　　　　　　 　　　　　　　　Adaptar　　→　　　Adaptee 194 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:29:13 ] まあ、↑みたいにするAdapterパターンの説明としては複雑になるから 省略してTargetをクラスにしてるんだと思うけど 195 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:00:04 ] クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。 Client からは統一的に扱える、同じように見えるって側面を強調するなら インターフェースでいいじゃねえかと。 委譲のパターンでもTargetはインターフェースで説明できるのに そっちの方がより無駄のない本質的な説明になるのに、 なんでクラスなの？と。 (>>192では委譲・継承とクラス・インターフェースの組み合わせが逆だった。) ↓これが一般例で、他はもう特殊例でしょ？ 　　　　　　<<interface>> client　→　Target <|・・・・・Adapter ・・・・・|> Adaptee 　　　　　　　　　　　implements　　 　 uses ひどいところでは 継承使うパターンがデフォですよ、 単一継承でいかんともしがたい時には 委譲使うパターンで回避ですよ、 に近い説明すら行ってる。 なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。 それは15年前に通ってきた道だろう、と。 196 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:07:58 ] それをいったらデザインパターン自体が出てからだいぶ時間がたってるから 当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。 もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう 事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する サイトでも立ち上げてみればいいｗ 197 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:14:16 ] >>195 ＞↓これが一般例で、他はもう特殊例でしょ？ それは少し乱暴だと思うが・・・・・ そう熱くなるなよｗ 198 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 16:58:29 ] >>195 っていうか、「委譲」って言葉の使い方間違ってね？ 199 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 21:21:49 ] Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。 200 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 22:04:55 ] GoFのデザインパターンは、モデリングの世界の"Hello World" 見たいな物になってしまったンだと思うね 201 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 19:42:57 ] ほす 202 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 20:07:12 ] 「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね 203 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:41:05 ] ほす 204 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 13:53:11 ] いまさらデザインパターンを語ることはあるまい 205 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:24:09 ] デザインパターンってもう語りつくされたん？ 206 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:36:31 ] 語れるほど言葉を持たないというのが正確なところかｗ 207 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 18:06:31 ] これはよく使うパターンって何？ 208 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 03:12:29 ] Iterator 209 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 07:26:27 ] Singleton、Factory、Template あたりかなぁ。 210 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:45:02 ] こんぽじっと 211 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:47:05 ] こーるばっく、こまんど、 212 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:28:34 ] 微細主義，機能分割，集団無能化・・・ 213 名前：デフォルトの名無しさん [2007/02/10(土) 20:34:33 ] 結城さんのMLってどうやって送信先メールアドレスを変えるんだ？ 進級２つ登録したから古い方だけ購読解除できればいいんだが まぁ４月になればアドレスが使えなくなるから放置でもいいんだけど 214 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:10:48 ] >>213 それって面白い？ 215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:12:50 ] NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、 みなさんはどのように勉強されましたか？ 個人的には本で勉強したいので、参考になる書籍などを示してほしいです。 216 名前：デフォルトの名無しさん [2007/02/12(月) 19:33:51 ] age 217 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 19:38:25 ] boostのコードを読むと、すごい勉強になった 218 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:29:48 ] >>217 kwsk 219 名前：デフォルトの名無しさん [2007/02/12(月) 20:55:12 ] デザインパターンを勉強すると、 自分が頭良くなってスゴイSEなったってカン違いするヤツ、 多いよな・・・ 220 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:59:00 ] 一人前のSEって感じでしょ 221 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 11:29:01 ] GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、 その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、 どの様に考えてもプログラマの職域に属する事項であるかと 222 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:23:41 ] >>221 「マイクロアーキテクチャー」って一体何の事だか、 分かっている？ 223 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:58:25 ] SEではないな 224 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 08:14:40 ] 半導体設計が思い浮かんだ。 225 名前：デフォルトの名無しさん [2007/02/19(月) 23:50:05 ] >>219 結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ 226 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 23:54:41 ] 勉強が足らんな 227 名前：デフォルトの名無しさん [2007/02/20(火) 00:13:46 ] >>226 kwsk 228 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:24:41 ] フレームワーク使う側でも使う。 java.lan.io.* なんてデコレータパターンの塊だし コレクションフレームワークはそのままイテレータパターンの実装だし。 フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには それはもうファクトリやらテンプレートやらのオンパレードさ。 229 名前：デフォルトの名無しさん [2007/02/20(火) 00:33:57 ] >>228 ｉｏ自身がデコレータでしょ 使ってる側は意識しないはず イテレータは素人でも使うよ 230 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:43:25 ] イテこまし…いやなんでもない 231 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 05:36:30 ] つーか、あるものを利用するだけで自分では使わないんだｗ 232 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 15:50:13 ] プログラマなんてみんなあるものを利用するだけでしょ アセンブラでもマシン語でも。 233 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 23:18:29 ] いんや 234 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:22:45 ] ｺﾞﾌ！ 235 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:07:48 ] ちょっと皆さんに助言願いたい事があります。 例えば、ゲームプログラムなんですが、 あるキャラクタークラスYがあったとしてキャラクタークラスは内部に AI処理を担当するクラスZをコンポジションでもっていたとします。 で、AIのタイプにはいくつかあって（タイプA/B/C）、それぞれの タイプにも、細かく引数によってパラメータの指定ができるとします。 AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジションで 持っていてもまぁなんでもいいのですが、 他のクラス（ゲーム進行管理クラスなど）からそのキャラクターのAIの動作を 変更するために、例えばAI処理をタイプBに変更、そしてB特有のパラメータを設定できるとします。 こういう事を実現するために、現在はクラスZを持っているキャラクタークラスにも、 タイプA,B,Cいずれの処理に切り替えるメンバ関数、あるいはそれぞれのタイプ別にパラメータを 設定する独立したメンバ関数を設定しています。 でもこういう事をすると、AIのタイプを増やすたびにキャラクタークラスにもそれに応じた メンバ関数を追加する手間が必要になってしまいます。 もっとスマートなやり方は無いものでしょうか？ 236 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:14:56 ] 他のクラス　──→　AIクラス 　　　　　　　　　　　　　　△ 　　　　　　　　┌───┼───┐ 　　　　　　　　│　　　　 │　　　 　│ 　　　　　　　　タイプA　　タイプB　　タイプC だろ普通 237 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:17:20 ] >>235 ＞キャラクタークラスは内部にAI処理を担当するクラスZをコンポジションでもっていたとします これ、Composition とは言わないだろう…… ＞AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジション だから、Composition じゃなくて Strategy ＞からそのキャラクターのAIの動作を変更するために 今度は State？ ＞にもそれに応じたメンバ関数を どういうメンバ関数？　それほど増えるとも思えないが。 ＞もっとスマートなやり方は無いものでしょうか？ 無い。これが上限であり下限。 割りきりが必要。極端に変な動作はさせないほうが吉。 238 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:00 ] ｴｴェェェ・・・？ 239 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:40:37 ] >>235 他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか？ ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を 外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。 Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。 240 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:48:58 ] 書き間違えました。 誤：ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 正：キャラクタークラスにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 です。 241 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:35:06 ] >>240 ABCがAIだろうがキャラクターだろうが同じじゃハゲ 242 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:44:26 ] 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターA用のセッター 243 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:45:17 ] まちがいたｗ　　　　　　 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB用のセッター 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターC用のセッター 244 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:49:25 ] Javaで書くとこんな感じ 　　　AICharactor iaChar = ai.getCharactor(); 　　　PropertySetter setter =　PropertySetterFacotory.getSetter(aiChar); 　　　setter.set(iaChar,otherObject); 245 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:53:52 ] プロパティじゃなくてパラメータだなｗ 246 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 03:01:46 ] >>235 そういうときこそ継承使えばいいじゃない 247 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 11:37:58 ] 全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。 各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。 AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。 再コンパイルは必要だろうけど。 248 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 15:49:22 ] みなさん、ありがとうございます。 >>247 その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない 気がしていたんですが、それが一番手っ取り早いのかもしれませんね。 249 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 16:03:31 ] ・・・・・・・・ 250 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:16:05 ] パラメータをいじる権利のある人がAIを生成して もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構 251 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:45:05 ] >>235 なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。 252 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:59:31 ] オブジェクト指向ってホントウに垣根が高いんだな・・・・

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef