ゲームにおけるデータ構造・クラス設計・パターン2

**名前は開発中のものです。** · 2008/05/23(金) 21:10:59

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

テンプレ追加事項あったらよろすく

**名前は開発中のものです。** · 2008/07/22(火) 18:36:04

DirectXはMSだけ
あ、Dreamcastという例外があるか

**名前は開発中のものです。** · 2008/07/22(火) 20:52:26

ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。
DirectXそのものを使ってるかどうかは知らないが。

**名前は開発中のものです。** · 2008/07/25(金) 15:29:12

やってみて、無理と判断され、チームを外されることってある？

**名前は開発中のものです。** · 2008/07/25(金) 20:06:41

>>267
板違い

プログラマー＠2ch掲示板
http://pc11.2ch.net/prog/

**名前は開発中のものです。** · 2008/07/26(土) 01:19:05

いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。

**名前は開発中のものです。** · 2008/07/26(土) 02:28:02

アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね？

**名前は開発中のものです。** · 2008/07/28(月) 18:13:52

前者は状態フラグの配列なり持っておけば十分だろ
後者はなんだ？状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ

**名前は開発中のものです。** · 2008/07/29(火) 14:37:45

>>271
なるほど。フラグの状態で、出るコマンドを制御すればいいのか。
サンクス

**名前は開発中のものです。** · 2008/07/31(木) 18:14:30

メニューコマンドってみんなクラス化しているもんなのかな？
メニューオブジェクトを生成してどうこうみたいな。

**名前は開発中のものです。** · 2008/07/31(木) 21:20:41

ベタコードで記述したり構造体・配列のままより
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね？
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。

**名前は開発中のものです。** · 2008/07/31(木) 21:26:22

フロントコントローラーパターンとコマンドパターンでやります。

**名前は開発中のものです。** · 2008/07/31(木) 21:38:09

メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは
だいたい同じインターフェースを実装してる。

**名前は開発中のものです。** · 2008/08/01(金) 00:01:16

クラスメンバって全部privateにしてgetterでしか取得できないようにするべき？
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし

**名前は開発中のものです。** · 2008/08/01(金) 00:11:49

>>277
クラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。
たぶん何か間違っている。

**名前は開発中のものです。** · 2008/08/01(金) 00:14:41

>>277
俺も同じようなこと悩んでて、気がついたら両方混在してた。

「これはクラスじゃない、構造体なんだ！」
って言い聞かせながらところどころpublicにしてたりw

**名前は開発中のものです。** · 2008/08/01(金) 00:22:47

全部て
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて

**名前は開発中のものです。** · 2008/08/01(金) 00:28:14

排他制御や状態確認が不要ならどうでもいいかもだけど
コード書くのがマンドイだけなんじゃ？
まっしなIDEやプロパティのある言語つかうとかかな。

**名前は開発中のものです。** · 2008/08/01(金) 00:32:32

>>280
例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。

**名前は開発中のものです。** · 2008/08/01(金) 00:36:38

まて、そら元々アクセサの設計が統合可能だった場合だろ
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……

守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ？

**名前は開発中のものです。** · 2008/08/01(金) 00:47:59

>>283
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。

あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。

**名前は開発中のものです。** · 2008/08/01(金) 00:54:19

getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、
publicにした方が使う側は書きやすくでいいんじゃないの？と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・

**名前は開発中のものです。** · 2008/08/01(金) 01:01:50

しかもget()で取得するのが配列だったりすると、
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。

**名前は開発中のものです。** · 2008/08/01(金) 01:02:58

とりあえずpublicで書いていって、
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。

**名前は開発中のものです。** · 2008/08/01(金) 01:07:26

>>287
なるほど。あまりスッキリしないやり方ですが、しょうがないですかね。
いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。

**名前は開発中のものです。** · 2008/08/01(金) 01:09:03

特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。

**名前は開発中のものです。** · 2008/08/01(金) 01:19:38

c++での話だが速度はインライン展開されるの期待できるから問題ないし
メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。

**名前は開発中のものです。** · 2008/08/01(金) 01:32:56

>>290
こういうのって、センスが必要ですね・・・・。

ちょっと気になった事があるんですが、
自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、
わざわざgetterで呼び出して使う必要はないですよね？

class Foo{
private int a;
public int get(){ return a;}
public int calc(){
return get() * 2;
}

このようなcalc()の書き方に利点はあるのでしょうか？

**名前は開発中のものです。** · 2008/08/01(金) 02:26:05

getter,setterがpublicなら外部参照する可能性があるということで
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。

**名前は開発中のものです。** · 2008/08/01(金) 03:52:45

getterロボ

**名前は開発中のものです。** · 2008/08/01(金) 04:12:11

メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。

**名前は開発中のものです。** · 2008/08/01(金) 18:37:49

>>294
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。

**名前は開発中のものです。** · 2008/08/01(金) 19:02:25

理想と現実はだいぶ違うよな
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする

**名前は開発中のものです。** · 2008/08/01(金) 20:43:12

インターフェース中心の設計でプログラミングするんだったら
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。

**名前は開発中のものです。** · 2008/08/02(土) 00:14:18

ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる（ﾄｲｲﾅw

**名前は開発中のものです。** · 2008/08/02(土) 00:25:25

しかしgetやsetが乱れ飛んで読みづらくなることも

**名前は開発中のものです。** · 2008/08/02(土) 06:50:04

>>299
プロパティが欲しいと。

**名前は開発中のものです。** · 2008/08/02(土) 11:52:40

C#はそういう意味ではスマートだなぁ

**名前は開発中のものです。** · 2008/08/02(土) 23:43:30

ゲームのシーン管理ってどうすりゃいいんだろう

**名前は開発中のものです。** · 2008/08/03(日) 02:53:56

シーンつったってゲームによって全然違うからな
もう少し具体的に

**名前は開発中のものです。** · 2008/08/03(日) 16:40:36

>>301
現行のゲーム機はまだC++なんだよな

**名前は開発中のものです。** · 2008/08/03(日) 21:47:19

>>302
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。

そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、

結局どんな処理が必要などんなゲームなのか？
どれを止めると不味いか、どれは止めても復帰させれば問題ないか？
とかによると思う。

**名前は開発中のものです。** · 2008/08/03(日) 21:52:25

シーンて、どのゲームも
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの？

**名前は開発中のものです。** · 2008/08/03(日) 22:00:54

おいどんのシーンは一種のタスクシステム(笑)で、
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。

**名前は開発中のものです。** · 2008/08/03(日) 23:21:42

FFとかのムービーシーンの管理はどうやればよかですたい？

**名前は開発中のものです。** · 2008/08/03(日) 23:31:02

プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。

いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と

**名前は開発中のものです。** · 2008/08/03(日) 23:31:41

あれ？　ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス？

**名前は開発中のものです。** · 2008/08/03(日) 23:31:45

>>308
ムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。

**名前は開発中のものです。** · 2008/08/04(月) 17:38:42

うさんくさか博多弁多かたいね。なんかぐらぐらこく

馬鹿にしないでください＞＜

**名前は開発中のものです。** · 2008/08/04(月) 23:28:56

>>312
こらあげにまっことすまんかったぜよ。

**302** · 2008/08/04(月) 23:40:39

>>306
そうそうそんな感じ。

1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。

**名前は開発中のものです。** · 2008/08/07(木) 02:18:10

　　しーん…

**名前は開発中のものです。** · 2008/08/07(木) 15:44:15

【審議中】
　　∴∵

**名前は開発中のものです。** · 2008/08/24(日) 00:35:34

（審議が長引いています。今しばらくお待ちください）

**名前は開発中のものです。** · 2008/08/27(水) 21:03:35

キャラクターの状態って、どうやって実装してますか？
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか？
stateパターンでは無理？？？

**名前は開発中のものです。** · 2008/08/27(水) 21:31:52

それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う

ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。

マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。

**318** · 2008/08/28(木) 00:48:01

>>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。

**名前は開発中のものです。** · 2008/08/28(木) 01:16:45

>コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな！」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。

ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねｗ

**名前は開発中のものです。** · 2008/08/28(木) 01:34:35

最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな

**名前は開発中のものです。** · 2008/08/28(木) 03:20:26

関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。

**名前は開発中のものです。** · 2008/08/28(木) 09:12:41

そこで goto ですよ

**名前は開発中のものです。** · 2008/08/28(木) 10:11:26

某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。

**名前は開発中のものです。** · 2008/08/28(木) 11:46:09

javaは関数ポインタ使えないんだ・・・・

**名前は開発中のものです。** · 2008/08/28(木) 11:57:21

>>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。

**318** · 2008/08/28(木) 17:59:10

>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな～と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。
完成させることが第一と思っていてもついつい・・。

>>323,327
stateパターンですよね？

>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。

**名前は開発中のものです。** · 2008/08/28(木) 18:35:54

自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。

つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる？

**名前は開発中のものです。** · 2008/08/28(木) 19:03:37

むしろ可能な全ての表記法を試す勢いで！
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。

**名前は開発中のものです。** · 2008/08/28(木) 19:43:21

人が書いたソースを読むのって勉強になるけど、読む気が出ない……

>>328
>stateパターンですよね？
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。

**名前は開発中のものです。** · 2008/08/28(木) 20:37:26

＞状態という概念が無い

敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。

**名前は開発中のものです。** · 2008/08/28(木) 21:28:28

>>332
他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。

**318** · 2008/08/28(木) 21:30:31

>>329
コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。
今問題にしてるのは、主にこのうち後者２つです。
ただ、読みやすさは人それぞれなのかもしれません。

>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。

**名前は開発中のものです。** · 2008/08/28(木) 21:59:24

保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの？

**名前は開発中のものです。** · 2008/08/28(木) 22:18:17

ダライアス継承ってどんな継承？

**名前は開発中のものです。** · 2008/08/28(木) 22:22:03

>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる？

**318** · 2008/08/28(木) 23:04:17

>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。

>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。

**名前は開発中のものです。** · 2008/08/29(金) 00:44:03

ダライアス継承なんて初めて聞いたなあ

英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス（Darius？）はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな

**名前は開発中のものです。** · 2008/08/29(金) 00:50:36

ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える

**名前は開発中のものです。** · 2008/08/29(金) 02:39:33

Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん

**名前は開発中のものです。** · 2008/08/29(金) 06:43:42

http://ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50

**名前は開発中のものです。** · 2008/08/29(金) 10:26:08

>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)

**名前は開発中のものです。** · 2008/08/29(金) 14:31:33

>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw

**名前は開発中のものです。** · 2008/08/29(金) 14:34:13

>だったりしてw
いやだったりしてっつーかそれしかなくね

**名前は開発中のものです。** · 2008/08/30(土) 13:56:18

ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。

**名前は開発中のものです。** · 2008/08/30(土) 14:18:00

ドラえもん「ことわざゲーム」
これはいいアニメ。 ... ドラえもん藤子Ｆ不二雄アニメ
ドラえもん後期ドラえもん本編教育アニメコメント非
表示推奨緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar

**名前は開発中のものです。** · 2008/08/30(土) 14:23:18

なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク

**名前は開発中のものです。** · 2008/08/30(土) 14:32:04

夏休みも終わりって事さｗ

**名前は開発中のものです。** · 2008/08/30(土) 14:40:33

Bot使った宣伝書き込みかなぁ

**名前は開発中のものです。** · 2008/08/30(土) 15:36:27

なんかのマルウェアって聞いたが

**名前は開発中のものです。** · 2008/08/31(日) 15:40:22

A has B B has C C has Dのようなクラス構成で
Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に
Ｅを渡していくのはいいのかな？

**名前は開発中のものです。** · 2008/08/31(日) 15:45:26

いいんじゃね。

**名前は開発中のものです。** · 2008/08/31(日) 15:47:56

別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない

**名前は開発中のものです。** · 2008/08/31(日) 15:54:48

>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな～と
思ったんだよね

**名前は開発中のものです。** · 2008/09/02(火) 03:29:08

このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠

**名前は開発中のものです。** · 2008/09/02(火) 03:31:07

>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。　っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと）
本当はいいとも悪いとも言えないが。

**名前は開発中のものです。** · 2008/09/02(火) 17:16:20

CarクラスはTireクラスを４つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？

**名前は開発中のものです。** · 2008/09/02(火) 17:22:14

コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外

**名前は開発中のものです。** · 2008/09/02(火) 17:30:36

TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか？

**名前は開発中のものです。** · 2008/09/02(火) 17:36:03

>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。

**名前は開発中のものです。** · 2008/09/02(火) 17:40:44

タイヤが車に関心があるってどういう状況？

**名前は開発中のものです。** · 2008/09/02(火) 17:42:28

「パンクしたよ」って知らせてくれるんじゃね？

**名前は開発中のものです。** · 2008/09/02(火) 17:44:29

なるほど