イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです


このエントリーをはてなブックマークに追加

Modelってなに?の話

はじめまして、bigenです。
はじめましてじゃない人は、こんばんは。

ブログを書くにあたって、最近の「すげえ!」を色々思い出してみたんですが、
結婚式場たけえ!とか、水タバコうめえ!とか、
エンジニアブログにかけるネタが全然ありませんでした。

なので、前回さらっと触れたモデル(Model)について少し考えてみようと思います。

  • 1.モデルってなんだ・・・

  • 2.科学のときに使う「モデル」の意味

  • 3.じゃあデザインパターンでのモデルの立ち位置は?

  • 4.おわりに

1.モデルってなんだ・・・

あれからMVCパターンについて学ぶこともあったんですが、
「結局モデルってなんやねん!コントローラとの境目はどこやねん!」
というありがち(らしい)な悩みに行き着きました。

プログラミングの観点からモデルとコントローラの扱いについては
色々述べられていて、結局
「作りたいものに合わせて、柔軟に分担させよう。ただしアンチパターンはある」
といった感じでした。

そこで、わざわざ「モデル」という名前をつけられている意味から辿っていこうと考えました。
「なかで色々やるところ」という意味なら、「Application」でも「Processor」でもいいはずです。
なぜ「モデル」なのか?

2.科学のときに使う「モデル」の意味

科学で用いる「モデル」とは、

現実世界の現象を、本質を理解しやすくするために部分的な特徴だけに注目し、簡易的に表したモノ

です。
前回と言っていることが随分違いますが、
前回は「数理モデル」という、モデルの中でも特別なものを説明しようとしていました。
今回は、より一般的な「モデル」の意味を考えたいと思います。

例えば、「真ん丸な地球儀」は地球という物質のモデルの一つです。
地球儀は中心にマントルはありませんし、地表の凹凸もありません。
そもそも本物の地球とは大きさが全然違います。
しかし、国家間のおおまかな位置関係や、東京の裏側がだいたいどの辺りか
を理解するのには十分な近似物となっています。

このように、自分の必要な理解を得やすくするために、
重要な情報(地球儀の場合では、おおまかな相似比)だけを抜き出し、
簡易的に表したモノを総称して「モデル」と呼びます。

地球儀のような実際の物体で表されるモデル以外にも、
もっと概念的なモデルも存在します。

私たちは実は、小学生のころからこの概念モデルに接しています。

「太郎くんは100m進むのに1分かかりました。あと2分後には合計何m進んでいるでしょう」
という問題を考えてみましょう。
これを読んでいるほとんどの人(ほぼ全ての人)は、「300m」という答えをすぐに出せるでしょう。

ですが、その答えは本当に正しいのでしょうか?
現実世界で、太郎くんは最初の1分と残りの2分、本当に同じ速度で歩くのでしょうか?
最初の1分と残りの2分、同じ速度で風は吹き続けるのでしょうか?
空気抵抗は考えなくていいのでしょうか?

私たちがこの問題を聞かされた時、太郎くんの疲れ具合など分からないし、
分かったところで進む距離への影響を正確に考えるのはほぼ不可能です。
風の速度も空気抵抗も同じです。

そこで、現実世界の太郎くんについて考えるのはやめて、
「太郎くんは疲れを知らず、これまでと同じ速度で歩き、風や空気など歩く速度に影響を与える外的要因は全て無視できる簡易的な世界
の中で、答えを出しているのです。
これが、概念的なモデルです

3.じゃあデザインパターンでのモデルの立ち位置は?

ここでMVCパターンにおける、Model-View-Controllerの役割について、
よく説明に用いられる表現を見ていきたいと思います。

Model: アプリケーションデータ、ビジネスルール、ロジック、関数
View: グラフや図などの任意の情報表現
Controller: 入力を受け取りmodelとviewへの命令に変換する
出典: https://ja.wikipedia.org/wiki/Model_View_Controller

コントローラーは、「モデルやビューへの命令への変換」という表現があります。

ある一つの構造を表現するモデルというのは、どのような特徴に注目するのか、
どのように簡素化するのかによって、無数に考えることができます。

ユーザーから
「100m進むのに1分かかったよ。あと2分でどれだけすすめるか教えて」
と言われた時に、
「ユーザーの国籍を調べて、残りの2分はその国の平均歩行速度を使って考えるモデル」を扱うことにするのか、
「気象庁に問い合わせてその日の天気まで考えるモデル」を扱うことにするのかは、
サービスの設計者に委ねられているのです。

こういった意味で、ユーザーが与えた情報が、過不足なくモデルに必要なものであるとは
限らないのではないでしょうか。
そして、それを補い、あるいは削り落とし、つなぎ合わせることがコントローラーの役割のように思えます。

このようにモデルやビュー、コントローラーの役割を理解するのであれば、
現在のサービスのほとんどはユーザーインターフェースの時点で
「モデル」が必要とする情報だけを入力させる構造になっているものが多く、
「ビュー」が「コントローラー」の役割の大部分を担っているといえるかもしれません。

また、僕の身の回りで聞く「これってコントローラー?サービス?」と悩んでいる機能の多くは、
「モデル」の中に吸収されてしまうべきなのでしょう。

与えられた情報を減らしたり増やしたりするだけの部分は「コントローラー」として、
与えられた情報を加工し、新たな情報を自ら生み出す機能は全て集約して「モデル」として区別できそうです。

4.おわりに

ここまで読んでいただいてアレなんですが、
これは全て僕が考えた一つの解釈の仕方でしかありません。

こんな区別の仕方をして、プログラムの見通しがよくなったり、
実装がしやすくなったり、テストがしやすくなったりするとはあまり思いません。

この解釈をMVCと呼ぶことにするのなら、MVCというデザインパターンは、
現実世界のプログラミングに役に立つものではないのかも・・・?

MVCという言葉にこだわってプログラムの構造を理解したいなら、
やはり提案者がどのような意図でMVCを提案したのかをもっと知るべきかもしれません。

プログラミングって奥が深い。