■実はMVCってしっくりこないんです

例えばスーファミのFFみたいな、古典的なRPGの戦闘シーンを作っていて、「勇者がモンスターを攻撃する」。

勇者.attack(モンスター);

という設計だったとする。

これに「モンスターが毒を受けて、自死する」という挙動を追加するケースを考える。

毒.attack(モンスター);

やや複雑な変更になりそうだが、勇者の攻撃とのタイミングの差で、

• 攻撃しようとしたときに、モンスターが毒で既に死んでいた場合、勇者は振り上げた剣を納刀する
• 毒を受けているモンスターが勇者の攻撃(斬撃)で死んだら、毒に侵されて変色した血が飛び散る

のようになるとしよう。

さて、変更する箇所は...

まず、インターフェイス"攻撃者"をつくって、「勇者」、「毒」をその実装とする。加えて...

Model勇者への変更:

斬撃後に死んでいた場合(*) 、納刀する

入力Controllerへの変更:

攻撃前に既に死んでいた場合、攻撃できないようにする

Modelモンスターへの変更:

• 毒を受けているモンスターが斬撃で死んだら、変色した血が飛び散る
• 死んでいるかどうかを返すメソッドの追加(*)

しかしこの変更は非常に複雑だ...

困ったこと１

この設計変更によって、

• 斬撃 ⇒ 死ぬ　

が、

• 斬撃 ⇒ 死ぬ ⇒ 毒
• 毒 ⇒ 死ぬ ⇒ 斬撃
• 毒 ⇒ 斬撃 ⇒ 死ぬ
• 斬撃 ⇒ 毒 ⇒ 死ぬ

の４パターンに増えた(※ただし最後のパターンに関しては今回特に修正の必要はなかった)

攻撃者がひとつ増えるごとに、これらの分岐は倍、倍に増えていく怖れがある。

困ったこと２

あらたに攻撃者を追加すると、既存の攻撃者を変更しなければならない。

困ったこと３

この変更によって、全体の時間的な流れがよくわからなくなった。

例えばさらに攻撃者「呪い」を追加したとする。

するとModelモンスターには

• 既に毒を受けているときに呪いを受けたら
• 呪いを受けたあとに斬撃で死んだら

等々の分岐が並ぶことになる。この分かりにくさは単にStateパターンを導入しただけでは本質的には改善しないだろう。

考察

MVCにおけるモデル、は振る舞いを持ったデータだ。モデルが状態変化したとき、イベントが発生する。

しかしその状態変化が別のモデルの状態変化のタイミングに影響をうけるとき、モデルの設計はとても複雑になり、読みにくくなってしまう。

モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。

このような複雑さをプログラマが支配するのは、とても大変だ。

みなさんも体験したことがないだろうか、GUIで「ホニャララしているときにホゲホゲするとバグる」みたいな挙動を。

例えば私が愛用しているiOS版はてなブックマークアプリは、

1. 「人気」タブを選択して
2. 記事のリストを(更新するために)下にドラッグしながら
3. ドラッグしている指を離さないで、(空いてる別の手で)「新着」タブを選択する
4. そのあと指を離して、再び記事のリストを下にドラッグ

すると、上部に表示される「更新時刻」の表示位置がおかしくなる。

RPGの設計は、たとえば下記のように記述できるDSLを導入すると、劇的に改善する。

タイミング：毒 ⇒ 死ぬ ⇒ 斬撃　の順なら、納刀する
タイミング：毒 ⇒ 斬撃 ⇒ 死ぬ　の順なら、変色した血が飛び散る

オブジェクト指向ではこれはStateパターンとStrategyパターンを組み合わせることで実現できる。

でも、このような設計にすると、勇者やモンスターのモデルオブジェクトの責任は極端に少なくなってしまう。

加えてオブジェクト間のやりとりの複雑さがDSLに押し込められるので、オブジェクトの主体性も殆ど無くなってしまい、

結果、モデルオブジェクトの存在意義が怪しくなるだろう。

うん、ただのデータでいいや。

---------------------------

(*) 攻撃時に相手の状態を問い合わせるのが醜い。これを避けるには、モンスターが毒で死んだ時に勇者にイベントを通知して、勇者を”戦意喪失”状態に変化させる手がある。

Permalink | 記事への反応(2) | 01:34

ツイートシェア