3.1スマートな設計を心がけよう
思ってコピーするのを防ぐために、ブラインドコピーができないようにしておかなければならない。これから本書を通じて繰り返し聞かされることになると思うが、他のプログラマが予想できないようなことはやるべきでない。こうしたことはたいがいはトラブルの元になる。コードの一部をデストラクタのような箇所に隠すといった、トラブルの元になるようなことは絶対にやめよう。
3.1.2クラスの階層化はできるだけフラットに
ゲームプログラマがよく犯す過ちの1つは、クラスやクラス階層を自分のニーズ以上に設計したり、自分のニーズ以下に設計することだ。クラス構造を自分のニーズにびったり合うように設計するには訓練が必要だ。
ウルティマVII』ではクラスを作りすぎたため、しまいにはクラスにつける適当な名前がなくなってしまった。コンパイラはかなり酷使されたためクラッシュ寸前で、プロジェクトの終盤には名前空間に変数を追加することができなくなった。それで仕方なく、2つ以上のデータを格納するのにグローバル変数を使わざるを得なかった。つまり、新しい変数を2つ作るかわりに、そのデータを上位ワードか下位ワードに符号化してグローバル変数の中に格納したということである。プロジェクトが終わるころには、コンパイラはいつクラッシュしてもおかしくない状態にあったため、新しいコードを加えるのは恐怖だった。
何でもそこそこに
実話
オリジンに入って初めて参加したC++プロジェクトが『ウルティマVIだった。このプロジェクトをC++でやってみてC++がいかにクレイジーな言語であるかを初めて知った。コンストラクタ、仮想関数、継承といったC++構成物のパワーにすっかり魅せられた私は、基本をマスターすると、ソースのあらゆる行に最低3つ以上のC++構成物を入れてしまったのだ。何と愚かなことだろう。『ウルティマVIIのクラスには7層や8層に継承されたものもあった。親クラスがデータメンバを1つしか持たないクラスもあったが、これは基本クラスを拡張しようという無能な企てにすぎない。
これとは対極にある、C++プログラムによく見られるもう1つの問題がBlobクラスだ。これはブラウン他著の『アンチパターン』に詳しい。Blobは細々したものを詰め込んだクラスで、プログラマがそれぞれのもの専用のクラスを新たに作ることを怠った結果生じるものだ。本書に付属するソースコードでは、GameCodeApp クラスがおそらくこれに最も近い。しかし少し勉強すればBlobクラスを効果的に使う方法が見つかるはずだ。
『ウルティマVIにも同じようなクラスがあった。それはKitchenSinke というクラスで、このクラスにはありとあらゆるものが詰め込まれていた。実をいうと、私は『Microsoft Casino の中でもこういったクラスを作った。知的なプログラマにとっては吐き気をもよおすほどのものだ。このクラスは画面のデータとメソッドをカプセル化するはずだったが、結局、MFCに前からあったCWndクラスのようになってしまった。つまり、セミコロンとブレースの巨大なバケツの中にあらゆるもの