yotiky Tech Blog

とあるエンジニアの備忘録

『MVP4U』の概念のポイント

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は継承しない

適用するプロジェクト

  • 2人以上、開発3ヶ月以上、リリース後もアップデートして運用を続けるなどに該当する
  • これに満たないものへ適用するのはコスパが悪そう
  • これ以下、もしくはサンプルやプロトタイピング
    • VMの2層+Component/FrontOchestratorあたりを意識しながら作ると後で応用しやすい
    • Mでは、主に外部アクセスを切り出しておく
    • Component/FrontOchestratorでは、初期化をコントロールしやすいようにしておく
    • 加えてヒエラルキーのオブジェクトツリーとソースコードの親子関係をある程度一致させておく