-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590696デフォルトの名無しさん
2011/07/31(日) 18:24:47.150697デフォルトの名無しさん
2011/07/31(日) 18:43:30.06まあ確かになｗ
俺は、10年も前に出来た様なソフト （Webアプリ） の保守・アップデート案件で
ここ3年くらい専業テスターやってるけど、3年前と今年は丸々リファクタリングだわ。
0698デフォルトの名無しさん
2011/08/02(火) 07:38:46.350699デフォルトの名無しさん
2011/08/02(火) 09:38:35.61俺が五年前にフルスクラッチで書いたクラサバは、
今も各所で元気に稼動しております。
0700デフォルトの名無しさん
2011/08/04(木) 18:51:24.420701デフォルトの名無しさん
2011/08/04(木) 20:13:23.20減価償却が５年だからな、馬鹿な経営者はソフトを作り変える。
まっ仕事も増えるから批判もできんが。
0702デフォルトの名無しさん
2011/08/06(土) 20:07:16.41話が噛み合わないっつか，
「ブラックボックスでええんちゃうの？」 つても、
「モデル化できへん」とか
言い出すやからと仕事する羽目になったんだが
0703デフォルトの名無しさん
2011/08/06(土) 21:53:52.84入力と状態を引数に取って出力と次の状態を返す関数だよ、くらいでいいだろ
0704デフォルトの名無しさん
2011/08/07(日) 12:58:04.510705デフォルトの名無しさん
2011/08/07(日) 15:27:21.39ええんちゃうの(笑)
できへん(笑)
そんな気持ち悪い言葉を使っているから意志の疎通ができないのでは？
0706デフォルトの名無しさん
2011/08/16(火) 23:05:37.94関西なら関西弁が普通でしょ
0707デフォルトの名無しさん
2011/08/17(水) 19:39:41.33はどの派生クラスのメンバー関数が呼ばれてるのか分からなくて解析が
困難になるから困ると思う人は俺以外にもいるかいな。
0708デフォルトの名無しさん
2011/08/17(水) 20:17:45.78それは思うが、メソッドのコメントアウトで結構どうにでもなる。
0709デフォルトの名無しさん
2011/08/17(水) 22:49:57.19既存ソースを変更しない為だから、既存のソースを読む必要はない。（機能が分かればいい）
とは言っても、既存のソースを読まなければならなくなるのも現実だから
最低限トリッキーなコードは書かないぐらいの対応はすれば十分だと思う。
だいたい、読みやすい読みにくいは、その個人の技術力や経験に関係するから
誰にでも分かるよようなコードだと、初心者向けのコードになるけど、それは違うと思う。
0710デフォルトの名無しさん
2011/08/18(木) 02:08:14.230711デフォルトの名無しさん
2011/08/18(木) 03:53:24.03それはお前が馬鹿なだけｗ
ただ、あると便利なのは事実だな。
最近はポリモーフィズムとかで
メソッドの候補が複数あるとき、
ちゃんと候補を出してくれる。
0712デフォルトの名無しさん
2011/08/18(木) 21:42:40.72どんだけレベル低いんだよ。クラス図見ろよ
といいたいところだけど、ロクに設計されずドキュメントも起こさず
思いつくままにダラダラと派生クラス作成してる現場も沢山あるよな
と思った。
0713デフォルトの名無しさん
2011/08/18(木) 21:46:55.76だがしかし、簡単に想像はつくな。
チームでやっててアホな展開にどんどん突き進むような場合。
0714デフォルトの名無しさん
2011/09/08(木) 20:41:41.88じゃあおれはJIT
0715デフォルトの名無しさん
2011/09/11(日) 14:20:51.11間に生成クラスみたいなのをはさんだほうが良いでしょうか？
0716デフォルトの名無しさん
2011/09/11(日) 14:25:54.820717デフォルトの名無しさん
2011/09/11(日) 18:08:15.00そのまま扱う場合と、オブジェクトにマッピングして使う場合があると思いますが
（この場合のマッピングは、機能のラッピングではなくフィールドへのマッピングです）
どのような設計基準で使い分けるといいでしょうか？
0718デフォルトの名無しさん
2011/09/11(日) 18:20:22.54というのも最近の開発環境ではIDEを使うのが一般的で、
IDE上ならメンバ名の自動補完やヘルプを参照しやすいのでプログラミングし易いから
対してそのままSQL的にアクセスするのはメンバが不定/未定な場合に使うときがある
すっごく稀なのでヒューマンエラーをものともしないテスト以前の動作確認のときに使うかな
ただし個人的意見なのであまり参考にならないな
0719デフォルトの名無しさん
2011/09/12(月) 23:00:05.33レスポンスやスタックオーバーフローとかの問題でどうしても
そのままのデータを使用しないといけない時がありますよね。
開発の途中で問題が発生した場合など影響が大きいので
あらかじめ配慮してつくるべきなのかなと思っています。
0720デフォルトの名無しさん
2011/09/12(月) 23:58:24.90>ありがとうございます
いいぇ、私は何もしていません。自分自身で解決していると思います。
>data_d:array[0..10000000,0..30] of double
Integerの場合は、「data_d:array[0..10000000,0..60] of Integer」と定義しても大丈夫なんでしょうか？
>>312
>静的配列と動的配列はメモリ確保の方法が全く違うんだが
すみません、"全く違う"とはどう違うんでしょうか？教えて下さい。
>>313
>ローカル変数として確保しようとしてスタックオーバーフロー起こしただけだったりして
すみません、ローカル変数の確保がなぜ”スタック”オーバーフローになるのか、教えて下さい。
0721デフォルトの名無しさん
2011/09/13(火) 11:01:06.03スタック消費するならオーバーフローするのは当たり前な気がするが・・・？
0722デフォルトの名無しさん
2011/09/15(木) 00:28:47.64実体を持つstaticフィールドを1個だけもち、全てのインスタンスが、そのフィールドに問い合わせ
するようにしても同じじゃん。
classs Logger
{
private static LoggerCore core;
public Logger()
{
if( null == core ) core = new LoggerCore();
}
}
0723デフォルトの名無しさん
2011/09/18(日) 12:37:17.44何が便利なんだか、わからん。
ただ、LoggerでLoggerCoreの全てのメソッドを、いちいち委譲しなきゃならなくなった
だけなのでは？
0724デフォルトの名無しさん
2011/09/18(日) 13:30:35.43Core自体は処理をもたなくてもいいんだよ。
言語によっては構造体でいい。
あと、シングルトンで継承しない場合はともかく、
したほうが良い場合でも、staticメソッドを使う場合は
上手く継承できない。
更に言えば、コンストラクタでオブジェクトを生成するのを
前提としたインターフェースに対し、staticメソッドでオブジェクトを返す
シングルトンオブジェクトだけは特別扱いしなきゃならない。
object.exampleNew(Logger.class); //Singletonも他のクラスと同様に生成できるべき。
0725デフォルトの名無しさん
2011/09/18(日) 17:37:53.97new LoggerCore(); でインスタンスを生成されると困るから
Singletonにするのでは？
0726デフォルトの名無しさん
2011/09/18(日) 17:48:03.390727デフォルトの名無しさん
2011/09/18(日) 19:10:47.820728デフォルトの名無しさん
2011/09/18(日) 19:21:34.270729デフォルトの名無しさん
2011/09/18(日) 21:31:28.690730デフォルトの名無しさん
2011/09/18(日) 22:25:49.47「Coreが処理を持たない」って、データだけ持つの？それで隠蔽化できてるの？
あと、シングルトンであるべきか否かはクラスの責務で決まるはずだから、継承したら変わるのでは？
まぁ「コンストラクタでオブジェクトを生成〜」は分からんでもない。シングルトンオブジェクトを
ラップするクラスを作る必要があるので、確かにこれに似た状態になるな。
0731デフォルトの名無しさん
2011/09/18(日) 22:31:28.55>>726が実現できるのは、内部クラスを作れる言語だけだ。
0732デフォルトの名無しさん
2011/09/18(日) 22:31:59.86class Logger
{
private static class LogField
{
int data1;
int data2;
}
private static LogFiled core;
public Logger()
{
if( Logger.core == null )
{
Logger.core = new LogField();
//必要なら初期化
}
}
//他coreを操作するメンバー
}
0733デフォルトの名無しさん
2011/09/19(月) 03:18:31.74例となるクラス図が載ってるサイトありますか？
0734デフォルトの名無しさん
2011/09/19(月) 22:01:52.57確かにそれでもシングルトンにはなるけど、
new Logger()だと中身が共有されてるってことを想像しづらいから、staticメソッドを使うんだと思う。
0735デフォルトの名無しさん
2011/09/19(月) 23:23:58.980736デフォルトの名無しさん
2011/09/20(火) 11:49:03.57むしろシングルトンと通常のオブジェクトを
インターフェース的に区別する必用がある？
0737デフォルトの名無しさん
2011/09/22(木) 01:05:30.38すべてのクラスは引数なしのコンストラクタを持つべきって主張してるわけじゃないよね。
シングルトンなんて使わずにモノステートを使おうよって話？
例にあるLogger自体はシングルトンじゃないから、シングルトンの説明に使おうとするなら根本的に間違ってると思うけど。
0738デフォルトの名無しさん
2011/09/22(木) 09:47:13.61引数があるかどうかはどうでもいいんだけど、
他のオブジェクトとインターフェースは同一にすべきとは考えてる。
リフレクションとか使う既存のリソースを再利用できるからね。
シングルトンと違うってのは、staticメソッドを使わないから違うって事言ってるの?
それとも空のインスタンスが生成されるから機能面で違うといってるの?
0739デフォルトの名無しさん
2011/09/22(木) 09:57:37.36モノステートとはちょと違うね。
例では分かりづらいけど、全てインスタンスメソッドだから。
0740デフォルトの名無しさん
2011/09/22(木) 21:07:57.85>>733
PACパターン で画像検索
0741デフォルトの名無しさん
2011/09/22(木) 22:10:00.87なるほどねー。ググったらstaticメソッドだらけのクラスを
モノステートと呼んでる所があったから違うと思ったけど、
ググり直したら全部インスタンスメソッドのものを
モノステートと呼んでる所があった。
これからはモノステートを
調べる事にするわ。
0742デフォルトの名無しさん
2011/09/23(金) 00:15:41.36完全に monostate が singleton の上位みたいな感じだな
よっぽど継承を封じ込めたくてfinalも無いような環境か
アドレスレベルで比較して同一と判断しなきゃならない場合を除いて
基本的に monostate を使っとけばいい感じだな。
0743デフォルトの名無しさん
2011/09/24(土) 22:41:09.72state/strategyとFactoryMethod使うと
OOっぽさが6割増し位になるよね
0744デフォルトの名無しさん
2011/10/21(金) 10:34:03.120745デフォルトの名無しさん
2011/10/22(土) 19:39:25.14自販機とかの架空の例や、顧客どうのこうのといった大きな例じゃなく、
小さなアプリを UML の記述から始めて OOP で作って完成させる例がほしいです
解説する言語も、プログラミング言語も問いません
数独ソルバ程度の小さなアプリであれば数独ソルバでなくてもいいんですが、
数独ソルバの例だとありがたいです
0746デフォルトの名無しさん
2011/10/22(土) 23:05:57.480747デフォルトの名無しさん
2011/10/22(土) 23:37:24.78いや、宿題じゃなくて・・・
関数型言語スレで、関数型言語だとUMLは書かないのかという質問があって、
OOP と FP でアプリの作り方（完成までの道のり）にどれくらい違いがあるのか興味が沸いて、
比較してみようと思いました
それで、既に UML を使った OOP での例があるなら、
OOP の方はそれを拝借した方が手っ取り早いと思っただけです
無いのでしたら、自分で両方の言語で試してみます
0748デフォルトの名無しさん
2011/10/23(日) 01:28:31.63一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
目的と手段をはき違えているように見える
もしどうしても数独ソルバにこだわりたいのなら、宿題スレへ逝ケ
0749デフォルトの名無しさん
2011/10/23(日) 02:12:11.39「数独ソルバでなくてもいい」 >>745 で言いました
> 一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
UML を使ってゼロから設計してアプリケーションとして完成させている例が無いです
「いくらでも」と言うのなら 10 例くらいWebページを挙げてほしいです
UMLで図を描いて終わってるページや、ソースコードだけのページはありますが
数独ソルバなら、パラダイム間で設計手法を比較する例としては
登場すると思われるクラスの数も多すぎず少なすぎず、
またデータが入力されたら解の出力まで処理が一直線なので、
クラス全体の関係を比較的見通し安いと思ったからです
今のところ他にいい例が思い浮かびません
また、FP の方では数独ソルバを既にゼロから設計して完成させているので、
OOP の方でも同じ例の方が楽です（別の例なら FP の方でも新規に作る必要がある）
べつに拘っては無いので、何度も言いますが、数独ソルバでなくてもいいです
> 目的と手段をはき違えているように見える
目的は >>747 のとおり設計手法の比較で、手段は（今のところ）数独ソルバですけど
履き違えてるように見えたのですか？
0750デフォルトの名無しさん
2011/10/24(月) 18:00:43.900751デフォルトの名無しさん
2011/10/24(月) 19:13:45.03無理かどうかはどうでも良くて、そういうWebページがないかどうかです
いくらでもあるそうですけど・・・
0752デフォルトの名無しさん
2011/10/25(火) 08:10:57.02そういう題材でサンプルを作ろうという話がそもそもない、というのはあるかもよ。
調べてないから想像だけど。
試しに、軽く自分で設計してみたらどうか。
0753デフォルトの名無しさん
2011/10/25(火) 08:14:31.30http://twitter.com/asami224/statuses/128609304684134401
http://twitter.com/asami224/statuses/128609800404746240
0754デフォルトの名無しさん
2011/10/25(火) 18:35:52.68その軽く設計ってのを省けるなら省きたいって質問なんだと思う。
すでに数独ソルバで片方やっちまってるからOOP版があれば欲しい、
ないなら数独ソルバには拘らないからOOPで設計実装してるの何かない？ ってことだと思うんだが。
あとどうでもいいけどFPって聞くと見積りの方が先に出てきて変な感じだ。
0755デフォルトの名無しさん
2011/10/25(火) 19:22:22.53その数独ソルバってのがよく分からないんだけど、多分アルゴリズム系だよね？
題材自体が、責務でインタフェース切ってオブジェクトに分割して、という方法論と
合わない気がするなぁ。
それ以外でもいいということなら、なんか著名な書籍を一冊買ってくるとかの方が早いかも。
0756デフォルトの名無しさん
2011/10/25(火) 19:46:20.70もの凄く分かりやすい代弁ありがとうございます
私も３行で自分の発言をまとめられる人間になりたい
>>755
私にとってはアルゴリズム系という意味の方がよく分からないのですが・・・
トイブログラムとか実験プログラム、検証プログラムとかの類じゃなくて、
ユーザーが数独の初期配置を画面に入力し、解答ボタンを押すと、
その数独の解答が表示されるというアプリです
当然、問題自体が間違っていて解答が複数存在すれば複数表示されますし、
解無しなら解無しと表示されます
すいません、その「著名な書籍」を一冊教えていただきたいです
今まで買ったオブジェクト指向の入門書や方法論的な本、UMLの本などは、
使えるアプリケーションとして完成させるまでに至っていませんでした
コアの部分をサンプルや例題として使ってオブジェクト指向的に考えたり、
アプリの全体的な設計図をUMLで表す道筋を何かのサンプルで示す、
というものばかりで、どちらも解説は丁寧ですが、「ゼロから完成」が無いんです
Webページも上記のパターンのどちらかのしか私は見つけられませんでした
いくらでも転がっているそうですけど
自分で作ってもいいんですが、私のようなオブジェクト指向未熟者じゃなく
お手本となるようなページを探してましたが、無さそうなので、とりあえず諦め、
拙いなりに自分でゼロから作る事にします
ありがとうございました
0757デフォルトの名無しさん
2011/10/25(火) 19:48:48.01正しい意味を始めて知りました
0758デフォルトの名無しさん
2011/10/25(火) 19:50:58.75すいません、意味合ってました
これだから電子辞書は ヽ(｀Д´#)ﾉ ﾑｷｰ
0759デフォルトの名無しさん
2011/10/25(火) 21:33:15.74ああなるほど、そういう「アプリケーション」レベルの設計の話か。
残念ながら、俺も「あるなら教えて欲しい」という感じなので力にはなれそうもない。
ただ、どんな手法でもウェブ上で「アプリケーションを一から設計して〜」というサイトは見たことが無い。
「ウェブは暇人によって支えられている」とは誰かの言葉だが、そういうメディアじゃないんだろうな、ウェブは。
なので本で探した方が確率は高いとは思う。
0760デフォルトの名無しさん
2011/11/05(土) 22:40:44.92TDDやプロトタイピング等で、ソースコードを設計書代わりにしちまうしなあ
0761デフォルトの名無しさん
2011/11/17(木) 13:21:21.981マス１マスをオブジェクトにするとかあるな。
マスに当てはまる候補を格納したり、
マスに所属するグループ持たせたり、
グループをオブジェクトで表現したり、
枠の判定を多態で表したり。
0762デフォルトの名無しさん
2011/11/28(月) 11:52:55.15・ネコ亜目 Feliformia
・ネコ科 Felidae : ネコ類、18属37種
・イヌ亜目 Caniformia
・イヌ下目 Cynoidea
・イヌ科 Canidae : イヌとその類縁、10属35種
この分類納得行かないよなｗ
イヌ科の元がネコ目だなんてｗ
0763デフォルトの名無しさん
2011/11/28(月) 18:13:25.550764デフォルトの名無しさん
2012/01/12(木) 23:56:38.89オブジェクト指向的な考えからするとdynamic_cast同様あまり良い設計とは言えないものなのかな？
0765デフォルトの名無しさん
2012/01/13(金) 00:24:26.78プロセス超えるからわざわざ書いてるだけで
面倒なだけだと思うけど。
0766デフォルトの名無しさん
2012/01/13(金) 00:39:51.73dynamic_castだとインターフェース以外にも正常にキャストできるけどQueryInterfaceはそれを制限できる、とか
直接的な継承関係がなくてもインターフェースを継承しているメンバのアドレスを返すことで代替できる、とか
0767デフォルトの名無しさん
2012/01/13(金) 20:27:05.48どいうこと!?
0768デフォルトの名無しさん
2012/01/13(金) 20:40:14.840769デフォルトの名無しさん
2012/01/13(金) 21:11:09.620770デフォルトの名無しさん
2012/01/13(金) 23:52:31.100771デフォルトの名無しさん
2012/01/14(土) 16:53:08.130772デフォルトの名無しさん
2012/01/14(土) 16:58:17.320773デフォルトの名無しさん
2012/01/14(土) 18:33:03.340774デフォルトの名無しさん
2012/01/14(土) 18:40:03.430775デフォルトの名無しさん
2012/01/14(土) 20:05:31.28この4つぐらいしか判定要素に使わんからワザワザ型判定する必要もない。
衝突判定対象要素の全に対し、この要素を取得できるようにしとけば済む。
0776デフォルトの名無しさん
2012/01/14(土) 20:39:43.40衝突するかどうかの処理じゃなくて
衝突した後どうなるかの処理だろハンドリングって書いてあるし
0777デフォルトの名無しさん
2012/01/14(土) 21:24:03.890778デフォルトの名無しさん
2012/01/15(日) 00:52:32.82ハンドラなんかいらない
0779デフォルトの名無しさん
2012/01/15(日) 01:02:23.53例えばタンクと下半身の壊れたガンダムが良い感じの角度と速度で衝突した時は特定のモーションを経て合体してガンタンクになる
というような処理は全オブジェクトに共通する通常の衝突処理フローでは実現できない
0780デフォルトの名無しさん
2012/01/15(日) 01:19:04.87オブジェクトを生成した際に特定オブジェクトのセットへの参照を
持たせておいて、衝突判定が降りた際、その衝突した
対象のID(もしくはポインタ)がセットの中に存在するかチェックすればいい。
そのほうが処理が早いし柔軟性も効く
0781デフォルトの名無しさん
2012/01/15(日) 01:42:58.29特殊処理が必要な型が増えるたびに冗長なコレクションを増やして、
しかも衝突するたびにそのコレクションから検索する、だなんてどうみても安くはつかないぞ
0782デフォルトの名無しさん
2012/01/15(日) 01:51:38.90> そのやり方はとても現実的とは思えない
なるだろうけど、らしく振る舞うだけなら省略できる部分がたくさんあるわな
つか、 計算しなくても済むところまで計算してるだろ？
0783デフォルトの名無しさん
2012/01/15(日) 12:19:27.31現実には0〜5程度。現実にはdynamic_castなんかより
setの方がコストは低いよ。とくにHash setにしてしまえば歴然。
あと、setであれば、その型が何かで限定する必然性は無くなる。
set<Tank*>, set<Gundom*> なんて分ける必要なく、set<Unit*>ひとつでいい。
入れられるオブジェクトを制限したい場合は別だろうけど。
コレにより、人間の見たキャラでクラス分けしなくて済むようになる。
機能でクラス分けすればよくなる。
0784デフォルトの名無しさん
2012/01/15(日) 13:04:50.24あるオブジェクトがその機能を持っているかどうかの問い合わせはそのレジストリから検索してあたりがあるかどうかで調べる
オブジェクトが死んだらレジストリから削除しなければならない
拡張によって特殊な機能が増えと新しいレジストリを作らなければならない
・ある機能を持っているオブジェクトかどうかそのオブジェクト本人に問い合わせる
拡張によって特殊な機能が増えてもその追加された機能を継承するクラスだけQueryInterfaceメソッドに1行追加するだけで良い
どっちが目的を明確に表していて、シンプルで理解しやすく、効率がいいのか、一目瞭然だろう
0785デフォルトの名無しさん
2012/01/15(日) 13:14:59.610786785
2012/01/15(日) 13:15:35.280787デフォルトの名無しさん
2012/01/15(日) 13:22:55.67パターン1個追加するたびに、関係するクラス全部変更ってのは不便。
人間始点ベースで組むと得てして拡張性は下がる。
たとえば、画面上のキャラ座標(固有ステータスも含む)と、
キャラクラス(形状データ、アクションデータ)はオブジェクトとして
一緒にしないでしょ。キャラ座標に、キャラクラスへの参照を持たせる。
拡張性を考えるなら見た目と、データ構造は一致し無いのが普通。
0788デフォルトの名無しさん
2012/01/15(日) 13:27:47.57>拡張によって特殊な機能が増えてもその追加された機能を継承するクラスだけQueryInterfaceメソッドに1行追加するだけで良い
無理
0789デフォルトの名無しさん
2012/01/15(日) 13:28:23.84>明確かどうかより拡張性さがるのが問題
>パターン1個追加するたびに、関係するクラス全部変更ってのは不便。
QueryInterfaceは拡張性ぜんぜん下がらないよ
むしろレジストリに登録する方がクラス間の参照関係、依存関係が増えて拡張性が下がる
0790デフォルトの名無しさん
2012/01/15(日) 13:33:06.07駒となるオブジェクトに持たせる必要が無いんだよ。
散々トポロジーの分野で使い古されてるネタだけど、
ある駒から、ある駒へのノードそのものをオブジェクトにして
そこにアクションを持たせておけばいい。
もちろんフルコネクトで繋ぎあわせると組み合わせが莫大になるから
その辺は、論理上のクラス(OOのクラスじゃない)で分けるんだけどね。
0791デフォルトの名無しさん
2012/01/15(日) 13:36:45.29そもそもQueryInterfaceをどうやって使う気なんだい？
クラスとオブジェクトのデータ構造が見えないから、
先入観で悪い使い方してるようにしか見えない。
0792デフォルトの名無しさん
2012/01/15(日) 13:45:24.19登録方式ならクラス間の依存性は増えないよ
他のクラスの事なんて全く知らないからね
0793デフォルトの名無しさん
2012/01/15(日) 13:48:01.12いまの流れで言ってるのは能力照会だよ
すごい適当に擬似コード書くならこんな感じの
衝突後処理(a, b)
合体可能インターフェース * p = 0; a->QueryInterface(合体可能インターフェースID, &p);
合体可能インターフェース * q = 0; b->QueryInterface(合体可能インターフェースID, &q);
if(p && q) { 合体処理(p, q) ; } // 両方共合体能力を持ってるなら合体
else { 通常処理(a, b); } // そうでないなら普通に衝突
>>792
クラス同士がお互いのレジストリクラスのこと知らないとだめじゃん
0794デフォルトの名無しさん
2012/01/15(日) 13:55:58.31const Kind gundom;
NodeSet set;
set.Register( new NodeActionA(), &tank, &gundom );
Unit unit_a( &gundom ), unit_b( &tank );
set.Conflict( unit_a, unit_b ).ActionDriven();
ノード制御ならこの3つを増やすだけだから楽だぞ
>const Kind xxxx;
>set.Register( new NodeActionA(), &tank, &gundom );
>new NodeActionA()
0795デフォルトの名無しさん
2012/01/15(日) 14:00:39.40それだったらQueryInterfaceやdynamic_castの類を使う必要はないよね。
単にIDを持ってるかどうか判定できればいいだけじゃん。
合体可能インターフェースなんて、クラスの依存性が増えるような物も必要ないじゃん。
0796794
2012/01/15(日) 14:08:48.56衝突情報を渡すの忘れてた。まぁいいか。
■ このスレッドは過去ログ倉庫に格納されています