ヘタれたアクセスメソッド

2002-02-01

この数ヶ月というもの，現実から斜め４５度横方向に目をそらしつつ，気付かないふりで自らを欺き耐え忍んできたのだけど，もうさすがに我慢の限界に来たようだ。ついに禁断のリファクタリングに手を出してしまう。

とは言っても，数千行のファイル１つを再構築しようってだけの話なんで，それほど大変な作業でもない。ただ，コードの再構築ってのはゲームの内容にはほとんど影響が出ない作業なんで，既にプロジェクトが作り込みの段階に入っている状態で行うには，少し覚悟が必要かもしれない。

みんなゲームとしての作り込み作業に一生懸命なのに，そういったことにまったく関係無い作業をいまさら始めるって，ゲームプログラマ的にどうよ，ってことにならざるを得ないのだ……ってのは，ちょっと肝っ玉小さ過ぎるかなあ。

とにかく，このまま放っておけば最終調整段階でままならないことになって苦労しそうな気配がすることは確か。最終的なクオリティを上げるためにも必要な作業なんじゃよ，と自らを説得しつつ，作業に突入する。

で，中規模ながらもしたたかに絡まってしまったコード塊を小さなパーツ群に分解しつつ，いちおう個々のモジュールを隠蔽する機構を追加していくんだけど，するとそのうちに，山のような数のアクセスメソッドを追加しながら虚ろにキーボードを叩き続ける自分の姿に気付く。だめだこりゃ。

void hoge_set_val(hoge_t *hoge, float val)
{
hoge->val = val;
}

float hoge_get_val(const hoge_t *hoge)
{
return hoge->val;
}

こんなヘタれたアクセスメソッドを書き連ねるぐらいだったら，いさぎよく hoge_t をエクスポートしろコラー！って感じなんだけど，僕はチキンなのでいちいちこういう余計なコードを追加しては，インストラクションキャッシュをぐしゃぐしゃにして実行速度を重くしてしまう。だいいち，このコードは hoge_t が val という内部値を持っていることを何ら隠蔽していないわけで，せいぜいアクセス制限を追加する機会を得たってぐらいのこと。本当に必要なの？

しかし，僕は基本的にヘッダに構造体の定義を書かないスタイルをとっているので，こういう単純なブリッジの役割をする関数はいやがおうにも増えてしまう。 C++ で書くときも，

class _Hoge;

class Hoge
{
  private:
    _Hoge *p;
  public:
    void set_val(float val);
    float get_val() const;
...

って感じで， private な部分はヘッダに書かないことを徹底してるんだけど，これもやはりコード量が飛躍的に増大するんで，書いてる途中でげんなりしてしまう。ていうか，２１世紀にもなってヘッダファイルなんて機構がまかり通ってる事の方がおかしいんじゃないか，っておもうことしきり，なんだけど。

ヘタれたアクセスメソッド

OBB vs AABB

XSLT

nanoloop

観察してみたり

OBB

UNC team gamma

ゲームコード

ゲームコード (2)

ゲームコード (3)

ISO14001

ファミコン音

ファミコン音 (2)

ダメ押し

nanoloop

ゲーム開発とか

GBA

Digita

PQP

V-Clip, BSP Tree

cbloom.com

Xbox

至極もっともな

虹色のトロツキー

発売記念ということで

PCM x 2 + GB

Effective C++

片面２層