表情メニュークラス
下記のScriptableObjectを定義
Menu
Folder
Pattern
Expression
別案
FaceMenu
FaceFolder
FacePattern
FaceEmote
Animation名前空間
Projectビューで直接参照したとき、メニューの構造と同じファイル構造になっていた方が分かりやすい
各クラスが自身のSerializedObjectを持つようにする
アクセス時にnullだった場合は新規作成
排他ロックする？
外部からSerializedObject経由でアクセスされると意味ないけど…
少なくとも、表情メニュークラスのメソッド経由でアクセスする場合はatomicにする
上位クラスでatomicにしてもいい？
Repositoryの仕事な気がする
データ閲覧時はSerializedObjectを経由しない
Update()の呼び出しコストを考慮
ApplyModifiedProperties()の呼び出し時点で値は書き込まれている
プロパティにしてしまうといいかも
getterはフィールドをそのまま返す
setterはSerializedObject経由で書き込み
https://www.stmn.tech/entry/2019/09/11/000539
privateなserialized fieldの命名規則を変更する
Viewへの変更通知をどうするか？
このクラスがReactivePropertyを持つ？
いつ破棄すればいいのか？
https://qiita.com/toRisouP/items/5365936fc14c7e7eabf9
MonoBehaviourの場合はOnDestroyで破棄
Usecaseが持つ？
各プロパティではなく、単一の変更通知Subjectを持っていてもいい
Expression単位で通知するとか
IMGUIは毎フレーム描画なのに通知が必要か？という話
ViewがModelの知識を持たないようにするために必要
UIElementsの場合は毎フレーム更新ではない？
表情メニュークラスは単なるデータオブジェクトであって、ロジックではない？
不要になったオブジェクトはDestroyImmeditateすること
https://www.f-sp.com/entry/2016/09/02/203000
Unityのリソース管理はどうなっている？
SerializableReactivePropertyを使うべきでは？
https://qiita.com/toRisouP/items/4344fbcba7b7e8d8ce16
SerializableReactiveProperty<T>を使うことで、ReactivePropertyをそのままUnityのインスペクターウィンドウに表示できるようになりました。UniRxでは任意の型を表示したいときにEditor拡張を用意する必要がありましたが、R3ではジェネリックをそのまま使うことができます。