MonoBehaviourを継承しないという選択肢【Unity】

この記事でのバージョン
Unity 5.4.0f3

はじめに

UnityではおなじみのMonoBehaviourですが、

デフォルトで継承されているし、ドキュメントにも以下のようにあるので、

Unityを始めた当初は絶対に継承しなきゃいけないイメージになりがちです。

MonoBehaviourはすべてのスクリプトから派生するベースクラスです。
Javascript を使用するときすべてのスクリプトは自働的に MonoBehaviour から派生します。 C# または Boo を使用するときは明示的に MonoBehaviour から派生する必要があります。

でも、いちいちGameObjectにaddするのめんどいし、

場合によっては使わなくてもいい場合もあるんじゃない？というのが今回の記事になります。

なお、C#についての話になります。

MonoBehaviourが必要ないケース

MonoBehaviourを継承しなくていい目安というかケースですが、

ざっくり言うと以下の2点だと思っています。

1. Hierarchy上に実体が必要ない。
2. Awake, Start, UpdateといったUnityが自動で実行するメソッドが必要ない。

例えば、RPGを作ろうと考えた時、

プレイヤーのクラスであるPlayerと、そのPlayerの能力値であるStatusというクラスを作ったとします。

PlayerはHierarchy上に実体が必要なので、MonoBehaviourを継承。

Statusは実体が不必要で、自動実行するメソッドも必要なさそうなので、MonoBehaviourを継承せず。

といった感じになります。

using UnityEngine;
using System.Collections;

public class Player : MonoBehaviour {

  //ステータス
  private Status _status = new Status ();

} 

public class Status{

  //能力値
  public int HP, ATK, DEF;

  /// <summary>
  /// コンストラクタ
  /// </summary>
  public Status(){
    HP  = 100;
    ATK = 10;
    DEF = 10;
  }

} 

もちろん、StatusにMonoBehaviourを継承させたり、構造体にしたり、

そもそもStatus自体がなくて、HP等をPlayerクラスに直接記述しても実装する事は可能です。

static

何かを管理するマネージャークラスなど、インスタンスが複数あると困る場合、

UnityではよくSingletonパターンが用いられます。

そもそもこれは、MonoBehaviourがstaticにできない為に使われている方法なので、

先ほど挙げた二つの目安をクリアし、かつインスタンスが複数あると困る場合や、

いつでも、どのクラスからでもアクセスしたい場合はstaticクラスを作るのが良いかと思います。

例えば確率の計算を行うクラスや時間を計る便利クラスなどが該当すると思います。

おわりに

記事中の例でもあった通り、MonoBehaviourを継承しなくてもいいという話なので、

全てのクラスがMonoBehaviourを継承しても実装可能ではあります。

なので最初のうち、特にプログラマーじゃない人は

とりあえず全クラスMonoBehaviourを継承させて作っていった方が楽なのかもしれません(:３っ)∋〜

---