君は知ってたか？スーファミのコントローラとMVCのコントローラは同じということ…を - ゲーム脳でもわかるMVC【序説】

# 概要

※続きの記事を書きました：読後にどうぞ
[【SAM】ゲーマー諸君、コントローラを棄ててアクションを起こせ！MVCのCが消えて、Actionが残った理由 - ゲーム脳でもわかるMVC 本論](https://qiita.com/sasanquaneuf/items/2926555c9f4e7230b84f)

この記事では、多様な意味を持つMVC=Model View Controllerという仕組みについて、**ゲーム脳の人にわかりやすい形式で**説明をします。
なお、MVCと単に記述した場合は、以下のようなものが歴史的な経緯によって混在しています：

- Smalltalkで実装された初期のMVC
- Web向けに構成されたModel2と呼ばれるもの
- さらにその他のもの

ここではModel2と呼ばれるものに近いニュアンスの説明をします。

![videogame_boy.png](https://qiita-image-store.s3.amazonaws.com/0/94255/7fd6e851-dfc7-0548-1dbb-d41d3511f762.png)

多分、この図に言いたいことが凝縮されています。

# MVCの目的（雑）

**保守性が少しでも高いコードを書きたい…流儀に従って読めば、迷子にならずに処理内容を把握できるプログラムを作りたい**

ざっくりですが、究極的な目的はこれにつきます。これを**UIを有するプログラムで**実現するにあたって、

**プログラムで行う処理の内容に応じてM/V/Cという３つの対象に分類して、分業・組み合わせ的な書き方を~~強制~~する**

というのが、MVC的な書き方という事になります。

# 登場人物の説明

身近な対象から説明するため、CとVから説明していきます。

## C：Controller

コントローラです。ゲーム機のコントローラを想像してください。WiiならWiiリモコン、64なら3Dスティック付きのアレです。
古いか。

## V：View

ビューです。「表示」「見えるもの」というようなニュアンスですが、要するに画面です。ゲーム画面が表示されているテレビを想像してください。

ここまで、ゲームをする時に触るのはコントローラで、見るのは画面ですね。

コントローラ…入力をつかさどる
ビュー…画面表示をつかさどる（出力とは言っていない）

さて、ゲームをするためには、一体何が足りないでしょうか？
これで外部パーツ的なものは揃っているように見えますが、肝心の、ゲームの処理をするものが実装されていないですね。それがMです。

## M：Model

モデルです。**ゲームのコア処理**を担当します。
コア処理てなんやねん、と思いますよね。入力受付と画面処理を除くと、ざっくり**内部データの処理**というものが残ります。
例えば…

- 大乱闘スマッシュブラザーズで、マリオがカービィのストーンを食らった時、どの方向にどれだけ吹っ飛ぶかを計算する処理
- オセロで、指定された場所に駒を配置して、他の駒をひっくり返す処理
- 迷路ゲームで、"指定された場所"に移動して、ゴールしたかどうかを判定する処理

このような、ゲームが内部で持っているであろうデータを用いて、ユーザーの入力とともに計算処理を行うようなものであって、**画面表示に依存しないもの**のことを、便宜上コア処理と呼ぶことにします。
今の画面がどこを表示していても、同じようにマリオがカービィからストーンを食らったら、同じように吹っ飛ぶはずですよね！だから一見Viewっぽくても、この計算の本質はModelです。

# イメージ画像

![main-qimg-6d8f5b34428e53c4cd4210961d071e32.png](https://qiita-image-store.s3.amazonaws.com/0/94255/c7d43781-c581-22b8-eedd-95e3e2918fb2.png)

# MVCの分業を迷路ゲームで体感する

では、実際にこの考え方に則って迷路ゲームを作ってみます。

これから説明する迷路ゲームでは、ユーザーはゲームのコントローラを模した「←↓↑→」に相当するhjklの情報しか送ることができません。入力をコントローラで受け取って、内部の処理では現在位置から動かしたりしますが、現在位置はコントローラでは受け取らず、差分のアクション（を示すデータ）しか受け取らない、というところが重要です。

```python3:maze.py
class MazeController:

    cursor_dict = {
        'h': (-1, 0),
        'j': (0, 1),
        'k': (0, -1),
        'l': (1, 0),
    }

    model = None
    view = None

    def process_input(self, input_str):
        if input_str in self.cursor_dict.keys():
            self.model.process(self.cursor_dict[input_str])
            return self.view.render(self.model)
        return self.view.render(
            self.model, message='h,j,k,lのいずれかを入力してください。')


class NormalMazeModel:

    world = list(list())
    current_x = 1
    current_y = 1
    message = ''

    def __init__(self):
        self.world = [
            [1, 0, 1, 1, 1],
            [1, 0, 1, 0, 0],
            [1, 0, 1, 0, 1],
            [1, 0, 0, 0, 1],
            [0, 0, 1, 1, 1],
        ]
        self.world[self.current_x][self.current_y] = -1

    def _get_next_place(self, diff):
        return self.current_x + diff[0], self.current_y + diff[1]

    def process(self, diff):
        new_x, new_y = self._get_next_place(diff)
        # 配列をそのまま使っているのでx,yに注意する
        if 0 <= new_y < len(self.world) and \
                0 <= new_x < len(self.world[new_y]) and \
                self.world[new_y][new_x] == 0:
            self.world[self.current_y][self.current_x] = 0
            self.world[new_y][new_x] = -1
            self.current_x, self.current_y = new_x, new_y
            self.message = 'GOGO!'
        else:
            self.message = '* おおっと *'


class NormalMazeView:

    world_map_dict = {
        -1: '@',
        0: '.',
        1: '#',
    }

    def _render_map(self, world):
        return '\n'.join([
            ''.join([self.world_map_dict[w] for w in world_row])
            for world_row in world])

    def render(self, model, message=None):
        if message is None:
            message = model.message
        return message + '\n' + self._render_map(model.world)


if __name__ == '__main__':
    controller = MazeController()
    controller.model = NormalMazeModel()
    controller.view = NormalMazeView()
    print(controller.process_input(''))
    while True:
        print(controller.process_input(input('')))

```

この例が、他のいくつかのMVCの例と比べて"わかりやすい"ところがあるとすれば、**コントローラで受け取る入力は、プログラムの内情を反映したものではない**というところかと思います。
一般的なウェブアプリの多くの画面では、データベースのテーブルとほぼ同じ形のフォームからデータを受け取り、モデルに処理をさせてビューに表示するという事があります。しかし、そのような一般的なウェブアプリの画面の形ではモデルの本質がわかりにくいです。
でも、このように差分だけを受け取るような事例では、わかりやすいです。

# もう少しだけMVCのメリットを感じる

ただ、MVCがそれぞれ一つずつしか存在しないのでは、本当にこのような形をしているメリットがあるのか？という事がわかりにくいかもしれません。
以下で、ViewとModelを増やした例を載せてみます。
具体的には、迷路の形を「ドーナツ型」に変更した場合のモデルクラスと、表示領域を狭くしたビュークラスです。

```python3:maze.pyに追加するコード断片
class TorusMazeModel(NormalMazeModel):

    def _get_next_place(self, diff):
        y = (self.current_y + diff[1]) % len(self.world)
        x = (self.current_x + diff[0]) % len(self.world)
        return x, y


class ShadowedMazeView(NormalMazeView):

    def render(self, model, message=None):
        if message is None:
            message = model.message
        # 画面の描画
        x, y, world = model.current_x, model.current_y, model.world
        viewable_world = [[
            world[i][j] for j in range(len(world[i])) if x - 1 <= j <= x + 1
            ] for i in range(len(world)) if y - 1 <= i <= y + 1]

        return message + '\n' + self._render_map(viewable_world)


if __name__ == '__main__':
    controller = MazeController()
    controller.model = TorusMazeModel()
    controller.view = ShadowedMazeView()
    print(controller.process_input(''))
    while True:
        print(controller.process_input(input('')))

```

この断片は差分であることに注意してください。
View/Modelを少しずつ変更してみましたが、これらは自由な組み合わせで正常に動くことを確認できます。
いまはcontroller.modelやcontroller.viewに手動でModel/Viewをセットしていますが、例えばこれがWebアプリの場合には、リクエストの内容によってモデル・ビューを動的に変更するというような挙動に繋がります。

一般に、決まった形式でModel/Viewを作るようにしておけば、処理を読みやすく・書きやすくなります。

# とはいえ、MVCのいま

ただ、ここまで述べてきたような有効な効果がありながらも、WebアプリとMVCに関しては以下のような言及もあります。

fluxのstoreはMVCのモデルではない
https://ledsun.hatenablog.com/entry/2018/05/16/105131
※タイトルやfluxという文字列は気にせずに、MVCの歴史などを見ると、いまの時点ではMVCが否定されています。

私がMVCフレームワークをもはや使わない理由
https://www.infoq.com/jp/articles/no-more-mvc-frameworks

個人的な認識では、それらは概ね正しく、つまり厳密にMVCを守るという事にはあまり重要性は無いかなと思っています。
ただ、MVCの根幹にある（はずの）、
**保守性が少しでも高いコードを書きたい…流儀に従って読めば、迷子にならずに処理内容を把握できるプログラムを作りたい**
という思いを実現する上では、このような考え方もある、という事を学ぶことに意味があるのかなと思います…いまも沢山のMVC風味のWebアプリが動いているはずなので。

おしまい。

…と思っていました。さっきまでは。
ところが、コントローラを棄てよ棄てよと内なる声が…！？

次回、
[【SAM】ゲーマー諸君、コントローラを棄ててアクションを起こせ！MVCのCが消えて、Actionが残った理由 - ゲーム脳でもわかるMVC 本論](https://qiita.com/sasanquaneuf/items/2926555c9f4e7230b84f)
に続く。

----

# 注意事項

この説明は、あくまでも概要を理解する為のもので、実際にはMVCと一言で言っても意味の「ゆらぎ」があったり、**フレームワークの実装がそもそも厳密な意味でのMVCに従っていなかったり**します。この記事はスタート地点、または**スタート地点に立つための筋トレの方法を示した記事**とご理解ください。（つまり、いずれにしてもスタート以前）
また、例に用いた題材が、必ずしもMVCでプログラミングされているという事を保証するものでもありません。

Controllerの中でViewを呼ぶことについては賛否あり、時としてファットなControllerの原因とも言われます。ここでは、ModelとViewの結合を疎にしたかった、ということでご理解ください。

DBの更新（永続化）に関する記述は…本題から若干ずれる部分があるので、今回は外しました。

型ヒントを使ってないとか、メンバ変数にそのまま代入して行儀が悪いとか、そのあたりも本筋から離れるので今回は雑に書きました。

Controller/Viewを作る際に継承するのはどうなのか？というのもありますが、コード量増えると読みにくいので継承してしまいました。NormalじゃなくてBasicとかにしといたほうがよかったかも。

renderなのに文字列返してprintしてないじゃん、というのは、jinja2やflaskを念頭に置いて書いてしまった為です。実は、Flaskにつなげるという構想もありました（量が増えるので削りました…）

（言い訳集みたいになった）