ゲームオブジェクト設計の変遷（つづき）

――仮にGhostのさらに基礎になる部分をEntityと名づけたとすれば、要求を満たすために多分こんな継承ツリーが生まれることだろう。

クモの巣だ。見た目も悪いが、今後の拡張の面からも不安がある。例えばもしEntityを継承するデータ構造がGhost以外にも現れたとしたら、3種類の機能を司るクラスの、この新しいデータ構造に依存する版をそれぞれ新たに作らなくてはならなくなるだろうし、その拡張作業はクモの巣をさらに酷い状態にしてしまうだろう。

このような継承の迷路ができてしまうのは、複数の設計的な目的を継承という手段だけを使って満たそうとすることに原因がある。上の図の各継承関係をその主な目的によって分けてみれば下図のようになる。

実装を段階的に拡張していっている青色の継承と、特定のメンバに依存しているという理由からの緑色の継承という二つの異なる次元でのシステムの捉え方が、一つの継承ツリーの中に押し込められているために、どちらか片方の種類が1つ増えれば、別の片方が今抱えているクラスの種類の数の分だけ、組み合わせ数が増えることになる。これを「継承原因の多元化によるクラス数の爆発的増加」というアンチパターンとして命名してみたい。（してみたいなぁ(*´ヮ｀*)）