トップページ⇒gamedev
1001コメント390KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2006/08/10(木) 20:27:06ID:BnvyxuCB
具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
0352名前は開発中のものです。2007/05/03(木) 21:53:36ID:ifdqR3nP
業務でもそれプラスユースケースくらい
0353名前は開発中のものです。2007/05/03(木) 22:57:52ID:ykGFiN+W
>>351
俺はアクティビティ図を抜いて、代わりにステートチャート図が追加って感じ。
0354名前は開発中のものです。2007/05/04(金) 13:14:26ID:ljy2orUl
> 憂鬱なプログラマのためのオブジェクト指向開発講座

これ、全然おもしろくなかた。
わかりにくい。
オブジェクト指向分かってる後によんだのに、わかりにくかった。

「プログラマのための 憂鬱なオブジェクト指向開発講座」に直すべき。
0355名前は開発中のものです。2007/05/04(金) 14:10:22ID:TiDrCtuu
そんな>>354のオススメ図書は？

いや、あおりでなしに、その本読んだけど分からなくて、今も分からないままなもんで。教えてくらさい　orz
0356名前は開発中のものです。2007/05/04(金) 21:08:31ID:+e+/DrXO
シームレスってどうやんの？
例えば2DのRPGマップをスクロールさせる様なばやいとか
0357名前は開発中のものです。2007/05/04(金) 21:14:04ID:osoiCnRq
>>356
普通にやれば言いと思うが・・・
どんな状況を言ってるんだ？

0358名前は開発中のものです。2007/05/04(金) 21:44:45ID:7VEgWe3m
>>356
マップをエリアに分割して、自分が今いるエリアの周囲をメモリに読み込んでおく。
移動して自分がいるエリアが変わったら、不要になったエリアの情報を破棄して
必要なエリアの情報を非同期読み込み。

これだけだが、何か疑問が？
03593562007/05/04(金) 23:07:32ID:+e+/DrXO
わかったありがとちん。
作ってみるよ。
0360名前は開発中のものです。2007/05/05(土) 00:05:52ID:WcHz0Tx6
>>355
あー、俺は、Delphiを使っているうちに覚えてしまったたちでね・・・。
当時は、標準添付ライブラリのVCL使ったり、ソースとか読んだりして、オブジェクト指向を学んだな。

今なら、.NETのライブラリ使ったり、コンポーネント作って、覚えるようなもんだろうか。

習うより、慣れろって感じでスマソ。


あえて言うなら、実践的なオブジェクト指向ということで、
デザインパターンの言及しているwebページとか、本とかかな？
直接関係ないが、開発技法になっちゃうが、XP（エクストリームプログラミング）関連とかも、
OOP前提が多くて、実践的でためになる。
リファクタリング、ユニットテストなど。

あと、Javaでかかれた本とかページとかは、オブジェクト指向前提で参考になるよ。
0361名前は開発中のものです。2007/05/05(土) 01:04:52ID:EPC7H7SP
なんとなくだが、>>360は見栄を張ってる気がする。
“ためになる”　“参考になる”とか言いつつも具体的な書籍やHPも挙げないし、
言ってる事も理解へ向けてと言うよりも言葉で煙に巻く感じで（・Ａ・）ｲｸﾅｲ!!

自分なら>>355には、　 オブジェクト指向プログラミング入門  を推す。
内容にがやや教科書的/板書的過ぎるから普通の読み方じゃなく
章単位の読み方とか多少英語論文的な読み方が求められるけどページ数に合った力がつくと思う。

あと、ここでなんか批判されまくってるが、「憂鬱な」はそんな悪い本じゃないと思うぞ。
まぁちらほら賛成できない部分や論理的におかしい部分は見受けるが、それでもなかなかの良書。
もう一度、読み直してみるのもいいと思うが。
0362名前は開発中のものです。2007/05/05(土) 02:25:29ID:WcHz0Tx6
アホか。見栄はりに2chに来てねーよ。
煙に巻くつもりなら、レスしなけりゃいい。

具体的なページを上げられないのは、当時のをブックマークしてないから。
第一、コード書いて、読んで、実地で学んだと言っているのに・・・。

ただ、「デザインパターン」とか「エクストリームプログラミング」とかキーワード上げてるんだからさ・・・
まあ、ググレカスと言いたいところなのだが・・・


■デザインパターン
サルでもわかる 逆引きデザインパターン　第1章 はじめてのデザインパターン　はじめに
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html

Amazon.co.jp： オブジェクト指向における再利用のためのデザインパターン: 本: エリック ガンマ,ラルフ ジョンソン,リチャード ヘルム,ジョン ブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,本位田 真一,吉田 和樹
http://amazon.co.jp/o/ASIN/4797311126/
流行になった本だが、実例少なく今となっては読みにくい。CDの中身がまとまっていてよい。

Amazon.co.jp： デザインパターンとともに学ぶオブジェクト指向のこころ: 本: アラン・シャロウェイ,ジェームズ・R・トロット,村上 雅章
http://amazon.co.jp/o/ASIN/4894716844/

Amazon.co.jp： 増補改訂版Java言語で学ぶデザインパターン入門: 本: 結城 浩
http://amazon.co.jp/o/ASIN/4797327030/

0363名前は開発中のものです。2007/05/05(土) 02:26:17ID:WcHz0Tx6

■リファクタリング
オブジェクト指向は直接関係ないけど、おすすめだから読んどけ。

Amazon.co.jp： リファクタリング―プログラムの体質改善テクニック: 本: マーチン ファウラー,Martin Fowler,児玉 公信,平澤 章,友野 晶夫,梅沢 真史
http://amazon.co.jp/o/ASIN/4894712288/
プロでこれ読んでない奴いたら、殴っていい

Amazon.co.jp： Java言語で学ぶリファクタリング入門: 本: 結城 浩
http://amazon.co.jp/o/ASIN/4797337990/

ちなみに、コメントないのは、俺が読んでないものなので注意（わかりやすそうなのを上げといた）


長いURL書き込めなくて苦労したぜ・・・
0364名前は開発中のものです。2007/05/05(土) 02:33:04ID:WcHz0Tx6
あとは、OOPしてる読んでおきたいソース。

一応ゲーム制作技術板だから、ゲーム系のソースでも上げとこうか。

ABA Games
http://www.asahi-net.or.jp/~cs8k-cyu/

Titanion
http://www.asahi-net.or.jp/~cs8k-cyu/windows/ttn.html

とりあえず、ふつーに、OOPしとるんで読んで参考になること請け合い。
規模はでかくないが、ABA氏の一通り完成されたゲームばかりなので勧めやすい
あと、D言語やJavaばかりだから読みやすいよ。
0365名前は開発中のものです。2007/05/05(土) 04:41:51ID:nOa25t75
初心者ならオブジェクト指向狂詩曲がいい。
内容はたいしたことは無いが、ＯＯＰの作法みたいなものがわかる。
軽く読めるのでおすすめ。

ところでダックタイピング系の書物でおすすめない？
0366名前は開発中のものです。2007/05/05(土) 09:36:59ID:WcHz0Tx6
>>365
ダックタイピングって、Rubyとか、Pythonのアレですか？
C++とかで実装する方法とかってことですか？

そんな局所的な本なんてでてんのかなー。

0367名前は開発中のものです。2007/05/05(土) 12:08:35ID:+5LnnL0c
ェネリックプログラミング系の書物がそれにあたるような気が
0368名前は開発中のものです。2007/05/23(水) 19:36:40ID:yFXY+8Zs
たまにネタふり。

2Dゲームなどで使われる
オーダーリングテーブル（Ordering Table）は、すでに常識でしょうか。
たぶんローカル用語でしょうけど、大体用語がないので、これですませています。

おれは、弾幕ゲーム作ってるんだ！
いちいち、物体ごとに、Zソートしてたら遅くなる！そんな時に使用します。

z値ごとに、ArrayListをもって、バケットソート（バケツソート）するような感じです。
z値が広い場合は、z値を狭めるか（0〜100くらいの定数にしてもいい）、
z値を割って使用します。

図では、こんな感じ。

z値
0　→□→□
1
2　→□
3　→□→□ →□→□
4　→□→□

□は物体。
0369名前は開発中のものです。2007/05/23(水) 19:39:22ID:yFXY+8Zs
>大体用語
代替用語
0370名前は開発中のものです。2007/05/23(水) 20:10:55ID:yFXY+8Zs
>>368
登録するのを物体ではなく、メソッドポインタなどにすれば、より汎用性が高まると思います。
0371名前は開発中のものです。2007/05/23(水) 20:13:35ID:tJZKFF0H
久々に凄いネタ振りを見た
0372名前は開発中のものです。2007/05/23(水) 20:46:34ID:sQffGK0m
人いたんだこのスレ
0373名前は開発中のものです。2007/05/23(水) 21:17:01ID:h3A9cPXz
ぶっちゃけZソートで重いって8bitCPUかと
0374名前は開発中のものです。2007/05/23(水) 21:37:02ID:5lNumVZr
最近知って、自慢したくて仕方なかったのでしょうw

使いどころ違うしw
0375名前は開発中のものです。2007/05/24(木) 00:12:03ID:sQQ2EGyG
>>368
> 物体ごとに、Zソートしてたら遅くなる！
今ならZバッファ使えばいいじゃん。PlayStation じゃないんだし。
0376名前は開発中のものです。2007/05/24(木) 00:19:50ID:4PByfCCv
>>375
画像処理のことなのか?
まぁ、半透明使うならZソートしといたほうがいいけど

>>368はハッシュとかツリーとか勉強するといいかも
0377名前は開発中のものです。2007/05/24(木) 14:14:16ID:MN3OTeQA
>>375
3Dのシーンならそれでいいんですけど、
2D主体で、アルファ付きテクスチャ描画が標準、
アルファブレンドを使うのが当たり前、加算合成などが多めになると、
Zバッファが使えなくないですか？

俺、もしかしたら、基本的なところで、ミスってる？('A`)

>>373
毎フレーム、オブジェクトを数千個ソートするのもそんなには重くはないですけどね。

>>374
実は、昔から(DirectDrawの時代)から使ってるんですが、
使いどころ間違ってるのあｋ−−−−−マジ教えてくれ

>>376
そうです。半透明が多めなんです。

Hashとかﾂﾘｰは普通に使います。OTの実装もHashと同じですし
0378名前は開発中のものです。2007/05/24(木) 15:21:37ID:4PByfCCv
hashとかわかってるならなんでそんなことをココに書き込むのだと小一時間問い詰めたい
0379名前は開発中のものです。2007/05/24(木) 15:43:03ID:a3uG9+mx
・２D主体かつαブレンドを多用
・z値が整数で適当な範囲に収まる場合
ならその方法がいいのかもね
でもゲームによってやり方を変えるのが一番賢いだろうね
0380名前は開発中のものです。2007/05/24(木) 16:17:32ID:aFaY4/D0
>378
最初にネタふりって書いてあるやん
0381名前は開発中のものです。2007/05/24(木) 16:34:16ID:uojugi7P
っていうか、2Dのスプライトの場合はZオーダーなんてそう頻繁に
入れ替わるものではないから、前フレームのソート結果を上手く利用すれば、
もっと軽くできると思う。
0382名前は開発中のものです。2007/05/24(木) 16:58:41ID:FtXKITOW
このスレの90％はネタを振る人間とそれにケチをつける人間でできています
0383名前は開発中のものです。2007/05/24(木) 20:02:03ID:K0O2WDIn
>>382
残りの10%は？
0384名前は開発中のものです。2007/05/24(木) 20:07:39ID:KUhBCX3E
ROM
0385名前は開発中のものです。2007/06/04(月) 17:52:58ID:wXEt1jZx
ROMはいくらいても0%だろう
0386名前は開発中のものです。2007/06/12(火) 16:35:34ID:KXWIMOSu
同人の俺は気にするほどのゲーム作らないからなー。
後から基数ソートやらに書き換えるつもりでSTLのsortでZソートしたけど
どこにも問題ないのでそのままリリースしたよ。めっちゃ富豪的
0387名前は開発中のものです。2007/06/12(火) 20:19:56ID:mHZMnLTI
>>386
PS2 でも、そんなもんでした。STLport にお任せ。
0388名前は開発中のものです。2007/06/18(月) 14:54:09ID:oOcxT9uX
コールバックってどういうときに使うんですか？
タスクシステム(というかハンドラオブジェクト)を使う時の場合において適当な例を教えてください
0389名前は開発中のものです。2007/06/18(月) 15:00:56ID:2wNoPL2v
コールバックする時。

タスクシステムに限らず、メモリの解放を行ってもらうときとか、
進展情報を表示する時によく使うなあ。

とくに前者の場合は、他の開発環境で作ったDLL内でメモリを解放したいときとか。
0390名前は開発中のものです。2007/06/18(月) 16:26:41ID:1gQkyo9F
>>388
オブザーバーパターンは便利だよ。
たとえば敵を倒したときにそいつのはいた弾をすべて消すとか、誘導弾のつけなおしとか
なれてくるとほとんどこれだけでイベントベースでコードが出来上がる。
0391名前は開発中のものです。2007/06/18(月) 20:21:44ID:nIlBSYV8
タイミングが判明する場所と、そのとき行いたい処理との間の結合を
疎にしたいとき使います。
ほとんどこれだけでとか関係なし。必要なところへ必要なだけ使うべし。
0392名前は開発中のものです。2007/06/19(火) 02:59:21ID:cFac+yZB
>>388
C時代のコードを利用するとき。
C++使えるんならほとんどのコールバックが仮想関数で見た目上は消せるだろう。

つまり仮想関数をCで使いたいときにコールバックが出てくる。
0393名前は開発中のものです。2007/06/19(火) 05:07:59ID:AmvqVn7S
>>392
あとは、スクリプト言語との連携とか。
0394名前は開発中のものです。2007/06/22(金) 08:30:52ID:njuyTnq1
Xboxのアレは禁断のボゴソートを使ったとしか思えない
0395名前は開発中のものです。2007/06/22(金) 15:30:47ID:G4eFb+Vh
>>395
Xboxのアレって何ですか？
0396名前は開発中のものです。2007/06/22(金) 17:18:36ID:vqNTOWGn
カルドセプトサーガの事じゃないの？
0397名前は開発中のものです。2007/06/22(金) 20:36:17ID:OntiNUWq
そのタイトル名でググってみたが、これは酷いなw
サイコロが奇数と偶数が交互に出るとかw
0398名前は開発中のものです。2007/06/22(金) 22:02:44ID:qN22ntrp
>>394
ボゴソートって知らなかった。
ttp://ja.wikipedia.org/wiki/%E3%83%9C%E3%82%B4%E3%82%BD%E3%83%BC%E3%83%88

これはひどいあるごりずむ
0399名前は開発中のものです。2007/06/22(金) 22:21:08ID:VTeo1nmT
>>398
これ逆にコーディングの手間がかかるだろｗ
0400名前は開発中のものです。2007/06/22(金) 22:22:42ID:+XVLd04M
＞ボゴソートは、ソートのアルゴリズムの一つ。
＞平均的な計算時間はO(n×n!)で、非常に効率の悪いアルゴリズムとして知られている。
＞安定ソートではない。

最後の一行のオチで吹いたｗ
0401名前は開発中のものです。2007/06/22(金) 22:28:33ID:0YS4QSdj
ここでボゴソートを使ったゲームを考えるのがゲームプログラマの努・・・ごめん無理
0402名前は開発中のものです。2007/06/23(土) 00:06:58ID:WPiear32
ボゴソートﾜﾛﾀｗ
0403名前は開発中のものです。2007/06/24(日) 05:25:19ID:zQnoyhbz
ﾜﾗﾀ
ソートつーか、バラバラに並び変えるアルゴリズムかとｗ
0404名前は開発中のものです。2007/06/24(日) 11:16:29ID:1MtSzEPe
>>400
安定ソートの意味知ってるのかよ('ω`)
0405名前は開発中のものです。2007/06/24(日) 11:33:03ID:NLW3QANP
>>404
安定ソートの意味知ってるのかよ('ω`)
0406名前は開発中のものです。2007/06/24(日) 11:35:30ID:rfvCjIOU
>>404-405
知らないよ！（ﾟДﾟ）
0407名前は開発中のものです。2007/06/24(日) 11:54:44ID:nOj+/xcZ
>>404-405
知らないよ！（ﾟДﾟ）
0408名前は開発中のものです。2007/06/25(月) 03:07:29ID:qVqBESx6
えーっと、同じ順位のアイテム同士はソート前の順番を保つ、であってる？
0409名前は開発中のものです。2007/06/25(月) 09:30:06ID:mc9m8oVn
あってる。
この記事のオチはInfinite monkey theoremだよ。ググレ、笑うから。
0410名前は開発中のものです。2007/06/25(月) 10:06:14ID:U5o2CqSM
セットで RFC2795 もどーぞ。
http://www.ietf.org/rfc/rfc2795.txt
0411名前は開発中のものです。2007/06/25(月) 20:59:14ID:NaYhg1aV
>>394-410
スレ違い
0412名前は開発中のものです。2007/06/25(月) 21:35:29ID:933SMbqm
>>411
既存のゲームにおけるパターンの一端って事で
0413名前は開発中のものです。2007/07/17(火) 22:54:23ID:Mh0Ht4Or
このスレ生きてますか？
基本的？なデータの扱いについて意見を聞きたいです

データに対応する操作クラス以外から値を書き換えることを禁止するためにこういうクラスを考えました
template <typename T> class IData {
public:
　　friend class Mutator<T>;
　　typedef T element_type;
　　typedef boost::shared_ptr< element_type > value_type;
protected:
　　value_type value;
};

template <typename T> class IMutator : public IData<T> {
　　typedef IData<T> data_type;
protected:
　　void assign(data_type& target) { value = target.value; }
　　void swap(data_type& target) { boost::swap(value, target.value); }
};
使う際はこいつを継承して
class CData : public IData<int> {};
class CMutator : public IMutator<int> {};
のようにすれば
CMutatorはIMutatorのassignやswapを使ってCDataのvalueの指すデータを生成から破壊まで自由に扱えるわけです

でもこのようにするとCDataの持つ情報が増えた時に
class CData : public IData<Param>, IData<Graphic>, IData<Sound>のように
継承しまくりになることとか、shared_ptrの機能によるコストが気になったりします

そこでもっと一般的なやり方を知りたいんですが何か良い方法ありませんかね？
0414名前は開発中のものです。2007/07/17(火) 23:05:36ID:oI0Vf9iA
template <typename T> class IData {
public:
　boost::shared_ptr<T> value;　　//!< 漏れ以外勝手に書き換えんなよ！
};
0415名前は開発中のものです。2007/07/17(火) 23:19:26ID:Mh0Ht4Or
いくら防衛策を巡らせても書く人の意思でいくらでも変えられるから
そんな事考えるのは無駄だよってことですか
言われてみればそういう気もしますが…(´・ω・`)
0416名前は開発中のものです。2007/07/17(火) 23:29:43ID:9lPCzUGd
多重継承にパフォーマンス(速度・容量の両面で)上の弊害は無いが
役割が酷似した基底(インターフェース)同士を多重継承って嫌過ぎだろ。常考。
衝突避けるためにインターフェース設計の段階でお互い調整しなくちゃいかんし
衝突上等ならキャストだらけの汚ねぇコードになる。俺ならコンポジットにする




0417名前は開発中のものです。2007/07/17(火) 23:32:47ID:ecw8MgBR
いまいち要求が飲みこめんけど、委譲とかプロキシパターンとか
アダプタパターンとか、ありもののパターンで十分間に合いそうな希ガス。

経験上、複雑な仕組みはロクなことがない。
Keep it simple stupidですよ。

苦労して得られる利益が少なくて割が合わないパターンでは？
0418名前は開発中のものです。2007/07/18(水) 00:07:21ID:xDBgIMCC
どうも
よく考えたらIDataはインターフェースじゃないっすね…
全く異なる型を同士でコンポジットにしてアクセスも上手く制限できる事って出来るんでしょうか

要求としては
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
です

操作されるデータの実体へのポインタを持つIDataと、それを扱うインターフェースIMutatorに分けたのは一番目のため
多重継承したCData経由でデータを扱うのは2番目を実現するため
データの実体へのポインタであるIDataのvalueメンバをprotectedにし
Mutatorをフレンドにしたのは三番目の為

以上によってゲーム内でのオブジェクトの振舞いは全てIMutator派生クラスのCDataに対しての操作として
書くことが出来て、リソースの確保等のシステム的な動作は外部に一任できる

という意図があったんですが、そんなに複雑ですかいね？
0419名前は開発中のものです。2007/07/18(水) 00:28:49ID:JHo6PQLB
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事

つまりテンプレートで実装する意味はないよね？
0420名前は開発中のものです。2007/07/18(水) 00:37:53ID:9FpPIZ4u
>>419
ないね
0421名前は開発中のものです。2007/07/18(水) 00:57:12ID:IHWjkDA2
> ・書き込み専用のクラス以外からのアクセスを制限する事

IMutatorを継承すればどんなクラス以外からでもアクセスできる以上、
制限できてるとは言いがたい。

「IMutatorの継承を無闇にするな」と、文書で説明する？
ならば、414でいいでしょ。
0422名前は開発中のものです。2007/07/18(水) 02:48:50ID:vN51PGaN
>>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること

「データ」と「ゲーム上のオブジェクト」の違いがよくわかりません。
「動作を〜に対して書ける」ってのもよくわかりません。
「〜を引数とする関数を書くことができる」ってことでしょうか？
0423名前は開発中のものです。2007/07/18(水) 05:52:53ID:1k3Xg7ZP
なんか奇想天外なことになってるのは
＞・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ
0424名前は開発中のものです。2007/07/18(水) 18:10:13ID:sTmzL7Mk
class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};

こうすると、CData::valueの型は何になるの？
04254132007/07/18(水) 19:28:34ID:xDBgIMCC
>>419,>>420
>つまりテンプレートで実装する意味は無いよね
恐らく既存の構造体を利用するためにこうした筈なんですが
普通にそれらをCDataにスマポで持たせた方がいいじゃんじゃんな気もしてきました

>>421
おっしゃるとおりです
細かいところにとらわれて本質を見失うという悪い例を晒してしまいました…

>>422
>「〜を引数とする関数を書くことができる」ってことでしょうか？
そうです
キャラクタの移動や描画の際は、リソースのハンドラを移動クラスや描画クラスに渡すんでなく
CDataを渡すような形で書きたいわけです

>>423
なんかキャラクタのクラスに座標構造体と移動メソッドを定義してたソースを友人に見せると
値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
何か思い違いをしてますか…と問うまでもなく明らかにしてますね

>>424
晒したコードでは見事に多重定義のエラーになりました
実際はそれ避けたり多重定義されたIDataのvalueを内部で扱うためにboost::mplとか使って
さらに複雑な事やってるんですが>>417氏の言ってる事に繋がりますね

とりあえず苦労して作った車輪は最発明どころかガラクタですらないナニカだったというオチでした
もっかい一から作り直してみますm(＿ ＿)m
0426名前は開発中のものです。2007/07/18(水) 20:55:21ID:ux1Fssbs
>>425
> 値を保持するクラスと操作するクラスは分けろこのスカポンタン
インターフェースと実装を分離するのは一般論としては間違いじゃないが、粒度が違う。
メンバ変数単位ではなく、意味のあるメンバ変数のセットをインターフェースにしろって
意味だと思うよ。


// 衝突判定後に、消灯判定マネージャから衝突回避のために位置をずらされる
struct IMovable {
　// 現在位置
　virtual void getPosCur(VECTOR3* p) const = 0;
　// 移動したい位置
　virtual void getPosNext(VECTOR3* p) const = 0;
　// 衝突しないようにマネージャがずらした位置
　virtual void setPos(VECTOR3 const& v) = 0;
};

class Player : public IMovable { ... };

class CollisionManager { /* こいつは IMovable だけ使用 */ };

こういう話かと。
0427名前は開発中のものです。2007/07/18(水) 20:55:52ID:ux1Fssbs
>>426
s/メンバ変数のセット/メンバ関数のセット/g
0428名前は開発中のものです。2007/07/18(水) 23:49:47ID:1k3Xg7ZP
>>425
＞値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの？
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ？
0429名前は開発中のものです。2007/07/19(木) 00:19:41ID:RaZNmmmq
> 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが

つかこれ自体間違いだろ。
0430名前は開発中のものです。2007/07/19(木) 00:38:54ID:PDuVn1ka
>>429
だよな多分
0431名前は開発中のものです。2007/07/19(木) 05:21:01ID:5YEt12VO
getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか（C++ならfriend？）

それ以上ってコストかかりすぎねえ？
0432名前は開発中のものです。2007/07/19(木) 11:40:10ID:LxxDZCLh
少人数・小規模製作でアクセス制限も糞もないわな
0433名前は開発中のものです。2007/07/19(木) 15:01:29ID:3ArgKadV
少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。

そういう場合は、アクセス権は考えといて損はねーですがよ。
0434名前は開発中のものです。2007/07/19(木) 18:50:40ID:TacCeKvZ
アクセス権？になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない
0435名前は開発中のものです。2007/07/19(木) 18:59:00ID:ajveBJeZ
とりあえず理由を
0436名前は開発中のものです。2007/07/19(木) 19:27:00ID:3ArgKadV
なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ？
04374362007/07/19(木) 19:27:51ID:3ArgKadV
変な日本語になった

正しくは、
なんでファイルのパーミッションの話になってるんだ
>>433のアクセス権って、クラスのメンバーに対することで、
>>432のアクセス制限ってのもそのことだろ？
0438名前は開発中のものです。2007/07/19(木) 19:39:53ID:/RFbeqQb
「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか＞ファイルシステムの例え話

個人管理のLinuxなんかだと、最初からrootでログインして使う人もいるくらいだから
それはそれで別に当人の自由だと思う。


要はアクセス権限を分ける方がトクか分けない方がトクかは
ケースバイケースで判断すればいいってことだけど
0439名前は開発中のものです。2007/07/19(木) 20:12:33ID:TacCeKvZ
＞なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん
0440名前は開発中のものです。2007/07/20(金) 12:39:13ID:vUDuhb3O
スレタイを百回声に出して読んでくれ
0441名前は開発中のものです。2007/07/20(金) 12:40:51ID:vUDuhb3O
ついでに二人とも正座な
0442名前は開発中のものです。2007/07/20(金) 21:52:02ID:+3gqdIHH
難しく考えすぎ。

他のオブジェクトにアクセスして欲しくないメンバは
クラスの中に隠蔽して、プライベートメンバにしておくのがセオリーでは。
アクセス権ってのは本来そうやってコントロールする。

外からオブジェクトにアクセスできるようにしておきながら
アクセスできないように制限する仕組みを作るってのがナンセンス。

0443名前は開発中のものです。2007/07/20(金) 22:07:32ID:lyxTTGt6
「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難
0444名前は開発中のものです。2007/07/20(金) 22:32:40ID:+3gqdIHH
動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。
0445名前は開発中のものです。2007/07/20(金) 22:52:28ID:+3gqdIHH
本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。

例えばnoncopyableはオブジェクトのコピーを禁止するクラス。
こんなレベルのものでも有用さが認められればboostに仲間入りできる。
http://www.kmonos.net/alang/boost/classes/noncopyable.html

でも今現在boostにアクセス権制御のクラスがないってことは、
需要がないってことでは？

まずはプライベートメンバを使ったシンプルな隠蔽によるアクセス制御で
どこまでできるのか突き詰めてみた方がいいでしょ。
今のところ自分はそれで困ったことはないけどね…。
0446名前は開発中のものです。2007/07/21(土) 00:49:20ID:DMrsrXyJ
ナンセンス。この一語に尽きる。
0447名前は開発中のものです。2007/07/21(土) 01:16:04ID:oWQ5iQEX
progress_displayがあるのにそんなこと言われても説得力無いなぁ

動的にアクセス権決めるならgetter,setterを隠蔽してfunction使ってアクセス権を与えたいクラスに
そのgetter,setterを与えてやるって方法もあるけど
functionは1個で40bytes近く食う割と重たい(？)オブジェクトだから無茶かな、無茶だな
0448名前は開発中のものです。2007/07/21(土) 03:00:31ID:DMrsrXyJ
動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ？RMIとかそーいった話の流れ方向での

静的だと外側の構造も知らん一クラスごときが誰に使われるのが良いだ悪いだ
決めるとか何いい気になってんだって話だ

>>443
＞静的に操作するのは困難
困難どうこうより、そのポリシーを決める根拠をどこにも求められないということだよ
適当に決めてしまえば後で直せなくなる
根拠がどこにもないから

0449名前は開発中のものです。2007/07/22(日) 02:55:07ID:/VC165Eo
>>443
インターフェースを多重継承して、必要な時・相手にアップキャストしたものを渡せば。
0450名前は開発中のものです。2007/07/22(日) 03:36:44ID:jrExVTdK
簡単な具体例も挙げてくださいお願いします
0451名前は開発中のものです。2007/07/22(日) 13:24:51ID:/VC165Eo
>>450
struct IFoo { virtual Vec3 getPos(); const = 0; };
struct IBar { virtual setPos(Vec3 const& pos) = 0; };
class CPlayer : IFoo, IBar { ... };

f1(IFoo&);
f2(IBar&);

CPlayer player;
f1(player); // f1には getPos() しかさせない
f2(player); // f2には setPos() でメンバ変数書き換えを許可
■ このスレッドは過去ログ倉庫に格納されています