WACATE名物と言っても過言ではない「夜の分科会」の二次会で、モデリングの話し合いをしてきました。その中で、「組み込み開発にMVCは使えるか」という話が出たのでまとめます。基本的に自分の主観を語っています。異論は認めます。
toshimana.hatenablog.com
はじめに
MVCについて勘違いをしていました。正しい理解は以下のリンクなどを参考にしてください。
at-grandpa.hatenablog.jp
私の理解では、MVCのMはシステムロジックという理解は正しかったのですが、View-Controllerについて勘違いしていました。Viewをシステム外部とのやり取り全般、ControllerはViewとModelの橋渡しだと勘違いしていました。正しくはViewは表示(システム外部への出力)、Controllerは(システム外部からの入力)になります。WACATEでは自分が誤った理解で話をしていたので、ここで修正しておきます。
組み込み開発にMVCは使えるか
MVCはWeb業界で広まった印象があるため、「MVCはGUIがあるシステム向けのデザインパターン」というイメージがあると思っています。Viewが表示、Controllerが操作であれば、GUIがない組み込み開発であれば、使い道がない印象を受けます。
私のイメージではViewはシステム外部への出力、Controllerはシステム外部からの入力となります。そのように解釈すると組み込みデバイスへの出力はViewで、組み込みデバイスからの入力はControllerで表現できます。ViewとConntrollerは強く依存していることが多いため、分離しない方がいいことが多そうですが。
ViewやControllerという言葉のイメージだと組み込み開発には使いにくいイメージがありますが、デバイスとの入出力をViewやControllerで表現する事でMVCを組み込みに活かすことができます。
MVCは1システム1つでなくても良い。
組み込みMVCで考えた場合、各デバイスに関する操作をサブシステムとしてMVCを用意した方が分かりやすい、という話をしました。例えばエアコンシステムの場合、エアコン本体をMVCで設計し、リモコンを別のMVCとして設計します。その2つのやり取りは統合したModelとして扱うと良いのではないか、と考えました。@dproject21さんの話では、統合したModelをサービス層と表現していました。
デバイス処理の抽象化
ControllerからModelに操作を渡す場合、処理の抽象度を変えた方が良いと思います。リモコンを例にすると、Controllerでは「電源ボタンを押す」操作を扱い、Modelでは「電源ON/OFF」という抽象化したイベントとして扱う方が良いと考えています。