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

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

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

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

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

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

**名前は開発中のものです。** · 2008/07/13(日) 03:29:10

つ単体テスト

いや出しゃばった　俺はweb系なので実情は判らん
まあロジック側は業種問わずどうグズったところで、
「何々渡したときに何々返す関数作ってー！」しか分業方法ないと思うけど

**名前は開発中のものです。** · 2008/07/13(日) 03:29:54

たぶん、作りかけってのが何処までか分からんけど
目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす＝エラーが出ないで動く　なので

**名前は開発中のものです。** · 2008/07/13(日) 03:32:16

http://wiki.game-develop.com/
wikiのチュートリアル→段階的学習でもやってみては

**名前は開発中のものです。** · 2008/07/13(日) 04:56:24

>>200
そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな？
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。

**名前は開発中のものです。** · 2008/07/13(日) 09:43:53

>>200
もし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。

だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。

早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、

**名前は開発中のものです。** · 2008/07/13(日) 09:51:14

>>204

>>200は外注や営業職の言い訳で多発するんだよね。
あんなのはまともに相手するのも無駄。
「スタブ要るじゃん。　スタブ供給してくれないとコストにあわないんだよね」系で、素で言ってのけやがる。
超ウケルんですけど。
こういうのに仕事を与えないようにするのが業界の為だろ。

　政治的な理由により取引継続となったら、「スタブの作り方を指導しますから、
その講習料として、スタブ作成代を相殺ですね」ぐらいしか案が無い。

・こちらはスタブなんて、要求仕様の一部で料金内。jk
・カス会社は、どちらも追加料金や有料。
・解決してなくても解決！！！！

**名前は開発中のものです。** · 2008/07/13(日) 10:22:09

>>194
作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。

RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。

**名前は開発中のものです。** · 2008/07/13(日) 10:49:52

作業分担？

全員が全体を上から下まできっちり把握した上で、
常に連絡を密にし、お互いが何をやってるのか理解しつつ、
各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。

**名前は開発中のものです。** · 2008/07/13(日) 11:17:51

>>208
全員が全体を把握できるのは、せいぜい3人ぐらいまでだな。その先は
ヒエラルキー作って、パート毎に管理業務やる人間を立てないと無理。

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

趣味ゲだと3人超えのマが介在するゲーム開発って
ほとんどないしな。大半はマが1人、多くて2人で>>408方式
ツーといえばカーの黄金タッグ。あ、ああじゃいる

**名前は開発中のものです。** · 2008/07/13(日) 13:48:37

×>>408　○>>208

**194** · 2008/07/13(日) 14:07:22

非常に参考になりました。ありがとうございます。

>>208
それ実際には各人に漏れやズレが出て手戻りが出るんで、大規模プロジェクトでは無理では

**名前は開発中のものです。** · 2008/07/13(日) 14:19:00

Cだったらmain()関数書いて実行して、デバッガ等で動き見るかな…
仕事（勿論?非ｹﾞｰﾑ）でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったｗ

個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどｗ

**名前は開発中のものです。** · 2008/07/13(日) 14:24:18

大規模が何人か明確じゃないし、作業形態もネット上だけなのか
サークルのようなものなのか会社なのかもわからないから議論が発散してる

フリーソフト作るのに主力のプログラマ2～3人と、バグ修正や機能強化の
パッチくれる人10人くらいでなら、MLとIRC使って>>208のような方針でやれてた

最初のバージョンはリリース済みで方向性が決まってたのが大きそうだ

>>212
作業するタスクを割り振りはちゃんとやって、頻繁なイテレーションと
継続的インテグレーションやるっつうのは何人くらいで破綻する？

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

>>214
１チーム１０人以下で、各チームにリーダー２人ぐらいで、２００人ぐらいのプロジェクトも回ってました。
素人なのでこれくらいしかわかりません。

**名前は開発中のものです。** · 2008/07/13(日) 15:15:30

>>215
プログラマの数は？

**名前は開発中のものです。** · 2008/07/13(日) 15:23:34

>>215
まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない（DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。

基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。

**名前は開発中のものです。** · 2008/07/13(日) 17:47:09

>>216
150人はプログラマでした

**名前は開発中のものです。** · 2008/07/13(日) 18:56:00

>>208は半分冗談、半分マジだったんだが意外と受け入れられてるｗ

>>218
なんの素人なんだｗ
ゲームでプログラマ150人規模って洋げーでも多分ないのでは。予算的に。

マジレスしますと、
小さい規模ならメインプログラマがほとんど一人で下位システムを作っちゃうし、
大きい規模なら別の部署が作るから、
「作りかけの状態でどうやってテスト・・・」という事態があんまり無いでつ

**名前は開発中のものです。** · 2008/07/13(日) 21:19:15

大規模金融システムで、SEの数ってことならありうるが
ゲームのスタッフロールにマが150人も並んでたら壮観だな

ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー

**名前は開発中のものです。** · 2008/07/13(日) 21:20:02

ネトゲじゃねーの？

**名前は開発中のものです。** · 2008/07/13(日) 22:39:48

マ150人てどんなネトゲだよ。。。

**218** · 2008/07/13(日) 23:00:22

ゲームのプロジェクトじゃないです。
詳細は言えませんが。

ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。

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

俺の知る限り、ゲーム開発では基本的にテストは無いです
単体テスト→結合テスト→受け入れテスト、みたいな流れは無い

昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません

なので大部分がデバッグチーム頼みです

**名前は開発中のものです。** · 2008/07/14(月) 00:00:22

3Dの衝突判定ライブラリを書いていたときは、単体テスト使いまくりだったぞ。

>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う

**名前は開発中のものです。** · 2008/07/14(月) 00:02:24

グラフィックやサウンドが絡む部分は自動化は難しいけど
ネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ

**名前は開発中のものです。** · 2008/07/14(月) 00:10:58

一人で作ってる分には単体テストに拘る必要はないと思うな。
逆に（自分含めて）しっかり単体テストできるなら、複数PG開発も悪くないと思う。
　　　　　　　　　　　^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁ｗ

テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな！

**名前は開発中のものです。** · 2008/07/14(月) 12:30:06

(NetBSDをOSに使ってる)リコーのプリンタの開発チームは
PGだけで1500人だそうです

**名前は開発中のものです。** · 2008/07/14(月) 15:33:56

数万行の同人ソフトしか作ったことないけど、ゲームってプログラムとしては割合小規模じゃね？
乗っかってるリソースの量がとんでもないだけで。

実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム（シーン別）、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の２乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。

あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。

**名前は開発中のものです。** · 2008/07/14(月) 15:36:32

>>229
勘定系だってそれほど変わらんよ。

**名前は開発中のものです。** · 2008/07/14(月) 15:40:51

RPGみたいないろんな要素のあるゲームのプログラミングってどこから手をつけていったらいいですか？

**名前は開発中のものです。** · 2008/07/14(月) 15:47:11

お好きなところからどうぞ

**名前は開発中のものです。** · 2008/07/14(月) 16:22:48

MSXのドラクエ２も大学生が一人で全部作ったんだよね

**名前は開発中のものです。** · 2008/07/15(火) 13:15:33

RPGっていってもいまだといろんなシステムあるからな～

古典的なドラクエ初期のように2Dオンリー

チョンゲーに代表される3D使ってるクリックゲー

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

P6のゼビウスは小学生が一人で作ったんだよね
(発売時は中学生？)
http://www.ne.jp/asahi/shiba/mic/nori/xevi_tiny1/index.html

**名前は開発中のものです。** · 2008/07/16(水) 17:02:22

>>230
勘定系は、人数は増えるけど PM しっかりしてればカオスにはならんよな。

金回りの話なのでミスが許されず、テスト工数がやったら膨らむから、
プロジェクト管理大変だけど。

**名前は開発中のものです。** · 2008/07/16(水) 17:02:59

>>231
メモリ管理

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

>>231
要素の洗い出し

**名前は開発中のものです。** · 2008/07/20(日) 02:44:36

先人のろくにコメントもないコードの解析だけで一ヶ月ぐらいコーディングもしないってことはありますか？

**名前は開発中のものです。** · 2008/07/20(日) 02:56:31

>>239
移植モノで、しかも元のプログラマが辞めて連絡取れないという条件で
一度やったことがある。二度とやりたくない。

**名前は開発中のものです。** · 2008/07/20(日) 03:05:04

ソースがあるだけマシだよ

アーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。

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

>>241
すみません…　それ、たぶんウチだ orz

**名前は開発中のものです。** · 2008/07/20(日) 03:39:46

最悪だなそれ

MAMEでも進呈したほうがいいな

**名前は開発中のものです。** · 2008/07/20(日) 15:36:02

オブジェクト指向のくずれてるウンココードに出会ったらどうしますか？

**名前は開発中のものです。** · 2008/07/20(日) 17:18:51

見なかったことにする

**名前は開発中のものです。** · 2008/07/20(日) 17:43:16

それ俺だな。
どうやれば良いか分からないから、手探りで書いてる(´・ω・｀)

**名前は開発中のものです。** · 2008/07/20(日) 22:53:25

シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない？

**名前は開発中のものです。** · 2008/07/20(日) 23:02:17

>>247
各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。

**名前は開発中のものです。** · 2008/07/20(日) 23:02:30

どういう意味？
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど？

**名前は開発中のものです。** · 2008/07/21(月) 01:05:54

>>247の文章が破綻

**名前は開発中のものです。** · 2008/07/21(月) 14:17:23

コメントにシングルトンと書かれてるのに２つも３つもインスタンスが
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn

**名前は開発中のものです。** · 2008/07/21(月) 18:53:57

XBOX360, PS3, Wii　売れ行きに関係なく、開発しやすいプラットフォームはどれ？

**名前は開発中のものです。** · 2008/07/21(月) 18:54:50

箱○

**名前は開発中のものです。** · 2008/07/21(月) 23:51:13

箱○は個人で十分開発できるからなぁ

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

箱○　天国
Wii 　普通
PS3 言わせるなｗ

という感じか？

**名前は開発中のものです。** · 2008/07/22(火) 00:03:34

>>255
詳しく

**名前は開発中のものです。** · 2008/07/22(火) 00:08:34

お前ら本当に3機種の開発ツール使ったことあるのかとｗ

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

なんで個人開発限定なんだよ

**名前は開発中のものです。** · 2008/07/22(火) 00:35:03

XNAのことを言ってると予想

**名前は開発中のものです。** · 2008/07/22(火) 02:21:06

XNAの市販ゲームが出たってニュースは前に見た気がするけど
実際どんなもんなんだろ

**名前は開発中のものです。** · 2008/07/22(火) 02:44:01

サターンのSBL,SGLしか使ったこと無い

**名前は開発中のものです。** · 2008/07/22(火) 02:45:19

360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話？

**名前は開発中のものです。** · 2008/07/22(火) 16:12:48

Wiiはインターネットチャンネルどころじゃない

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

ゲーム機はDirectXを使うの？

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