昨日のペラいネタですが、「なにこれいくら派生だからって多すぎでは」と言いたくなったのでつい書いちゃったんですあれ。

昨日の続きです。見出しひとつひとつでそれなりの分量で記事を書こうと思えば書けるものです、あれ。いくらなんでもペラペラすぎて私自身の役にすら立ってません。なのでもう少し詳しく書いていきます。

おこおとわり

紹介したどの手法も、「いかにロジックとプレゼンテーションを分離するか」の答えのひとつです。アプリを設置する環境、構築に使うライブラリやフレームワークによっては使えないもの、使えても恐ろしく開発が非効率になるものもありますが、これといって優劣はないと思います。

じゃあそもそも分けないとどうなるのか

多分保守作業が大変なことになります。

• 見た目を修正したらついでにデータが保存できなくなった
• ↑直したら今度は画面がまっさらになった
• 機能追加に時間がかかる
• ↑しかも追加した機能の数≪湧いたバグの数
• コードの流れがぶつ切りになってすごく読みにくい
• ↑開発者のコードを書く気力をもりもり食べたバグがどんどん湧いてくる

あたりは容易に想像できます。実際ネタに走らせるほうに時間を3倍ほど割いてます。おそらくこの開発現場は簡単に、ひどいときはそれこそ少しでもコードを追加した次の瞬間に、デバッグとエンバグを繰り返す賽の河原になります。

そこで改めてMVC

これではよくないので、機能で分けていきましょう。とりあえず、

• データの取得とか更新とかだけ、表示はほかに任せる
• データの表示だけ、処理はほかに任せる
• 利用者の入力を受け付けて、データや見た目の書き換えをしてもらう指示をする

の3つに分けてしまいまでょうか。それからこれ以降、上から順に「Model」、「View」、「Controller」と呼ぶことにしましょう。すると…

これがModel-View-Controllerパターンになります。この兄弟の中では一番有名であり、ほかのパターンはだいたいこれの派生形だと考えて差し支えないでしょう。

ライブラリに楽をさせてもらおう

ライブラリを使ってプログラミングすると、入力を受け付けてViewの書き換えをするだけなら、コードを書かなくてもできることがあります。私の知っている限りではこれをお手軽にやれるのは.NET Frameworkしか存じ上げませんが、きっとほかにもあるはずです。きっとほかにもあるはずです、素晴らしいライブラリ。そういったとき、うまくライブラリに楽をさせてもらうことができれば、Controllerは不要となります。

これがView-Modelパターンです。Controllerのおしごとは、私たちのコードに替わって、優秀なエンジニアが作った優秀なライブラリの優秀なコントロールが優秀なパフォーマンスでこなしてくれます。

長くなりそうなので今日はこれまで。続きは明日以降に。