こんにちは、今日はゲームで使える設計について解説したいと思います。
ゲームづくりはUnityを筆頭に近年段々と簡単になっています。簡単になっていますが、大規模なゲームを作ろうとすると設計をしっかり行う必要があります。設計というと難しい感じもしますが、聞いてみると当たり前と思えるものも多くあります。
今日はその中でも SOLID原則から「単一責任の法則」について解説したいと思います。
「単一責任の法則」とは？
ゲームを作っていると、キャラクタを制御するクラスにいろいろなメソッドを実装したくなります。無作為に作っていくとどんどんとクラスが大きくなるものです。
そして、大きくなったクラスの内部はいろいろな変数が複雑に絡み合うことになり、一つの変更がすべての動作に依存してしまう状態となります。
「単一責任の法則」はこのようなことにならないように１つのクラスが行うことは１つにしましょうというお話です。
しかし、この原則をそのまま使用すると大量にクラスが生成されます。複数作成するとその分内部で管理する変数が多くなったりと複雑性が増していきます。
Facade パターンで量産したクラスをまとめよう
クラスが大量に発生する場合は、Facade パターンを用いて、キャラクタの動作を規定した受付用のクラスを作りましょう。
Facade パターンはいろいろ複雑な処理を単一のクラスでまとめて、様々な処理の受付を行うパターンです。
でも、これでははじめの状態と変わらないように見えますね。ですが、「単一責任の法則」で考えるとPlayableCharacterFacadeはキャラクタの動作の受付になるという責任を持っており、それぞれのサブクラスがそれぞれの動作の責任を持つと見ることができます。
まとめ
繰り返しになりますが、「単一責任の法則」は１クラスがおこなうことは１つにしましょうという意味です。そして、責任を１つにすることで、変更があったときに他に依存しない設計にすることができるのです。
僕の体験談ですが
ゲームを作っていてもこのようなクラスが大量に量産されることはよくあります。ですが、長い運用を行っていくとすると、誰が変更を加えてもきれいなコードになるようにしなければいけません。「単一責任の法則」がきれいに適応されているプロジェクトは変更点の探索や、変更者の追跡なども簡単に行うことができて、誰が書いてもわかりやすく、書きやすいものとなります。
