2. Unityにおける設計レベル

Unityにおける設計を考える上で参考になるものがあります。それが、とりすーぷ氏が定義したUnityにおける設計レベルです。公式的なものではないですが、設計を考える上で有用なので取り上げます。ちなみに、第2回までの内容はここでいうレベル2を目指した内容となっています。

以下引用

設計レベルの定義

設計レベル	状態
-1	C#の文法がわかってない
0	設計なし
1	制御フローは整理されているが密結合な状態
2	制御フローと依存関係が分離した状態
3	モジュール化の意識が現れた状態
4	MonoBehaviourへの依存をやめた状態
5	「アーキテクチャ」が意識された状態

レベル-1: C#の文法がわかってない

「UnityのAPI」と「C#の言語機能」の区別がついていない状態です。
レベル-1を脱出するためには
- MonoBehaviourを使わないクラス定義のやり方を覚える
- 今使っている機能がUnityAPIなのかどうかの区別をつける

レベル0: 設計なし

後先考えず、MonoBehaviourを継承した上で手当たり次第に実装を行っている状態です。
この状態で1週間も開発を続ければ見事なスパゲッティコードが誕生することになります。
レベル1を目指すには
- まず何を作ろうとしているのかを明確にしよう
- オブジェクトの責務をハッキリさせよう
- オブジェクト同士の関係性をハッキリさせよう
- 制御フローをキレイにしよう

レベル1: 制御フローは整理されているが密結合な状態

「制御フローが整理されている」という状態です。
この時点でもMonoBehaviourは継承したままです。
多少の問題はあるものの全体が破綻するようなことは避けることができます。
ただしオブジェクト同士は密結合な状態のため、機能拡張や挙動の差し替えといった場面で難が出てきます。
レベル2を目指すには
- 「疎結合化する」ということを意識しよう
- SOLID原則を覚えよう

レベル2: 制御フローと依存関係が分離した状態

疎結合化が進んだ状態です。
この時点でもMonoBehaviourは継承したままです。
おそらくこのあたりが一番実用的なラインです。
「設計何もわからない」という人はこのレベル2を目指してみるのがよいでしょう。
レベル3を目指すには
- モジュール化に意識を向ける
- コンポーネントの原則を覚えよう

レベル3: モジュール化の意識が現れた状態

モジュール化の意識が現れた状態です。
詳細な設計ではなく、「モジュールとモジュールがどう関係しあってプロダクトを構築しているか」を見ている状態です。
「大規模開発」を見据えた状態ともいえます。
小規模開発ではレベル3を達成する必要性は薄いともいえます。
レベル4を目指すには
- モジュールからUnity依存を消していく
- より抽象的なモジュールに分離できないか考えていく

レベル4: MonoBehaviourへの依存をやめた状態

（もしかしたらレベル3とレベル4は反対かもしれない?）
MonoBehaviourへの依存をやめた状態です。
ピュアなC#の比率が増え、MonoBehaviourを継承したクラスの数のほうが少なくなってくる状態です。
「Unity」と「Unityが必要ない部分」の切り分けがハッキリしてきます。
レベル5を目指すには
- アーキテクチャの考え方を勉強する
- おすすめは「クリーンアーキテクチャ」

レベル5: 「アーキテクチャ」が意識された状態

アーキテクチャが意識された状態です。
「プロダクト全体の構成を頭に入れ、どのモジュールとモジュールがどのような関係で成り立っているか」のルールを詳細に決定した状態です。
ここまでくると完全に大規模開発を想定した状態であり、趣味プロのような小規模プロジェクトでここまでやるのは冗長すぎるかもしれません。

注意点

レベルが高いほど良いというわけではない
- レベルが高いほど長期的なコストが下がりますが、手間や学習コストも増えます。
- 自分たちのニーズに合ったレベルを見つけるのが大切。
設計レベルはハイブリッドにしても良い
- ある部分をレベル5で書き、またある部分をレベル2で書いてレベル5の領域に依存させても良いのです。