とりあえず、自分のチートシート用に作った。
（リポジトリ名がふさわしくない…。何でここにコミットしたんだろ）
以下、考察。
〇シングルトンパターンには、Unityに関しては2つの思想が存在する
1．MonoBehaviourを継承する物。こっちは、コルーチンやUnityのStart等の呼び出しに対応しているが、オブジェクトを生成する必要がある。
Github上の「SimpleMonoBehaviourSingleton.cs」が、これに該当する。
2．MonoBehaviourを継承しない物。こっちはオブジェクトの生成が必要ない。データコンテナなんかは、こっちを使う事が多い印象。
Github上の「SimpleSingleton.cs」が、これに該当する。
〇MonoBehaviourを使うパターンに関して、ベストプラクティスとされている物の考察
Github上の「BestPracticeSingleton.cs」が、これに該当する。
これは
Yaminabe:うにばな Unityのため50のヒントとベストプラクティス（2016年版）:意訳 - livedoor Blog（ブログ）
ここの方が載せている内容を参考（ほぼパクリ）にしている。
想定するに、この設計思想は、元々シングルトンを管理するオブジェクトが、ヒエラルキ上に存在することが前提で使う用だ。
個人的には、そのまま使うには使いづらい、というより不親切であるように感じる。
シングルトンと言われれば、Instanceアクセスすればいつでも使える、というイメージが先行している為だ。
では、これのメリットはどこにあるかと考えた時に、識者との話し合いの結果、オブジェクトに初期値を設定して反映できる点ではないかと言われて、腑に落ちた。
つまり、Unityエディター上でパラメータ操作をして即反映できる、設定ファイルとしての側面を、用意するオブジェクトに持たせることが出来る。
「SampleSingletonClass3.cs」が該当。
同じシングルトンでも、使い方が違う物をそれぞれ無秩序に使うのは混乱の元になるので、思考停止で全て使えばいいとは思わないけど、適切なルールの下で使えば、それぞれ使い道があるだろうという結論に落ち着いた。
