MVP
- ベースはMV(R)P
- Model(以下M)とView(以下V)の責務を別ける
- Presenter(以下P)は薄く、MとVを糊付けする程度の責務(主にRxで伝搬)
- View[V]はコンポーネントを束ねPに対するインターフェースを担う
- Usecase[M]はモデルを束ねPに対するインターフェースを担う
- ComponentはアタッチしたGameObject自体に作用するもの
- FrontOrchestratorはアタッチしたGameObjectに影響しないもので、Component同士の連携をサポートする
- ComponentOrchestrator、CompositeComponent
- 従来~Manager、~Contorollerと定義しがちだったものはこの辺に来ることが多い
- Component/FrontOrcastraorで階層を作ることでヒエラルキーのGameObjectとScriptの階層がある程度似たような構造になる
- データ、処理がUI/UXに作用させるためだけのものであれば、Component/FrontOrcastraor内で済ませ、P/Mは経由しない
エンジン
- MVP4Uは舞台をイメージした作り
- チャプターは暗転してシーンが切り替わるような時の1シーン
- 登場する人、物が入れ替わる(チャプターを跨いで存在しない)
- シナリオを通して必要な値はContext(文脈)として保持する
- エンジンはその辺を動かすための基盤なので無くても良い
- 代わりにチャプターを切り替える仕組みが欲しいところ
- Scene遷移では新たシナリオ(台本)に替えて舞台を改めて始める、そのための仕組みが欲しいところ
初期化順序
- 初期化の手綱をゲームループから奪還して手中に収める
- ゲームループからのエントリーポイントを1箇所に限定する
- それを起点に必要な初期化はスクリプト内で伝播させる
- 影響範囲が局所的で狭いComponentは、Startなどで処理しこの伝播に乗らなくて良い
Unityへの依存
- Clean Architectureを目指すならUnityに依存するのはVまで
- MVP4UはClean Architectureを目指さないので全体でUnityに依存してもOK
- MonoBehaviorを継承するのはVとPまで
- Pを含めるのは初期化順を制御したい
- ヒエラルキーの階層に見えててほしいから
- MでWebアクセスUnityのクラスを使う場合は、UniRxのObservable.FromCoroutineを使ってMonoBehaviourは継承しない
- Pを含めるのは初期化順を制御したい