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

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

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

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

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

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

**名前は開発中のものです。** · 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#はそういう意味ではスマートだなぁ