MonoBehaviour、ここ良いよね、ここツラいよねのメモ

経緯

私は手触りとしてはPure-C#クラスのほうが好きなので、特段の理由が無ければ、というか便利だと感じなければMonoBehaviourを使わない方針にしているけど
Unityエンジニアにこの話をするときにあまり納得してもらえないことが多いので
そのときのネタ帳が欲しくなった

プログラマは「コードを読む時間のほうが圧倒的に多い」という前提があり、リーダブルで安全なコードを書くにあたっての所感をまとめる

ここツラいよね：

MonoBehaviourだと生成タイミングを追うのが大変になる
Pure C#クラスだとコンストラクタの呼び出しを追えばいいが、MonoBehaviourはAddComponentされるか、プレハブからシーンに展開されるか、などになるので
そのMonoBehaviourへの参照が多い場合はコードベースで追うのが大変だし、プレハブであればコードベースから追えないこともある

ここツラいよね：

MonoBehaviourは生成のタイミングで依存するクラスの初期化を強制できない
Pureクラスであればコンストラクタに依存関係を記述できる

これは、クラス使用時に依存するクラスがnullでない可能性をコンパイラレベルで排除できないことを意味するのでnull厳格なプログラムと相性が悪い（いちいちnullable型にすればいいという話もある）

Pureクラスであれば、コンストラクタで指定したものはreadonlyフィールドにすることもできて良い

null合体演算子などでnull判定ができない

==では大丈夫だけど、component ??= GetComponent<>()ができない

ここいいよね

Disposeにあたる処理をOnDestroyに記述できる。
特に外部から明示的に破棄をしなくてもOnDestroyに書いてあれば自動で実行されて便利