時代に翻弄されるエンジニアのブログ

ゲームプログラマをやっています。仕事やゲームや趣味に関してつらつら書きたいと思います。

SOLID原則 ゲームで使える インタフェース分離の原則

f:id:tkymx83:20190120120159p:plain:w1000

こんにちは、インタフェースッテ肥大化しがちですよね。

そんなときに使える、インタフェース分離の原則について今日は解説したいと思います。

「インタフェース分離の原則」とは?

簡単に言うと、インタフェースは必要に応じて作成して、無駄なメソッドは追加してはいけないということです。

ではゲームで使われるキャラクタの制御についてインタフェースが肥大化した例を見てみましょう

インタフェースは共通部分の抽象化に便利

アクションゲームを作っていると、プレイアブルのキャラクタと敵キャラで処理を共通化したくなります。

その時は以下のように1つのインタフェースを継承する形で実装していくことになります。

f:id:tkymx83:20190120120213p:plain:w1000

共通部分を実装しているうちは効率よく実装ができます。しかし、各クラスで違いが出始めるとこのクラスは一気に崩壊します。

インタフェースは肥大化しがち

例えば、プレイヤーではキーボードで操作できるようにしたいから、入力メソッドがほしいと思うでしょう。

これを単純にインタフェースに追加すると、以下のように敵キャラ用に作成したクラスに対しても処理を書く必要が発生します。

f:id:tkymx83:20190120120234p:plain:w1000

この状態では2つのデメリットがあります。

  • 入力メソッドの変更が入るときに敵キャラにも影響が及ぶ
  • 共通ではないメソッドが複数追加されることでインタフェースが肥大化する

このように、せっかく継承したのに依存がどんどんと増えコードの複雑性が増加していきます。

インタフェースは必要なものだけまとめましょう

解決方法は単純です。インタフェースを必要な要素で作成して、必要なクラスにのみ継承させるということです。

f:id:tkymx83:20190120120248p:plain:w1000

こうすることで、入力メソッドの変更が敵キャラには影響しないし、今後入力系のメソッドが追加されても敵キャラには影響がありません。

まとめ

インタフェース分離の原則は、適切にインタフェースを切ることで不要な依存をなくし、それぞれのクラスの責任を限定するために使用されています。

個人の体験談ですが、

インタフェースが肥大化することで、必要なメソッドがわからなくなります。更に、コードが量も肥大化して神クラスと呼ばれる存在になり、プロジェクトの負債となっていきます。インタフェースが多数継承されている図は気持ち悪いと思われるかもしれませんが、それ異常に肥大化したインタフェースは複雑性を増す存在なので注意するべきです。