ViewModel設計の原則 その3

□導入

今回のブログでは、3番目の原則として「ViewModel設計を画面設計に位置づけ積極的に設計すること」を説明します。

順を追って説明するために、まずここでの用語の定義として、画面仕様と画面設計の言葉の使い分けについて説明します。その上で、ViewModelの画面設計について説明していきます。

なお、ここでの説明がどのプロジェクトにも適用可能な正しい内容であるかは分からないことをあらかじめご承知おきください。ここでの内容をそれぞれのプロジェクトで使用するのはもちろん構いませんが、すべて自己責任でお願いします。



□画面仕様と画面設計の言葉の使い分け

今後の説明を円滑にするため、ここでの「画面仕様」と「画面設計」という言葉を簡単ながら定義しておきます。

ここでの「画面仕様」というのは「どのような画面を作成するのか」という画面のWhatを定義するものとします。具体的には、どのような画面と画面遷移が存在し、どのような画面レイアウトで、どのような画面の項目があり、それらの画面項目は数字なのか文字列なのか、必須なのかあるいは上限値や下限値といった ものを定義します。

一方、ここでの「画面設計」というのは「どのように画面を作成するのか」という画面のHowを定義するものとします。具体的には後で説明するように、ViewModelのクラス図などがこれにあたります。

なお、他ではここでの画面仕様と画面設計という言葉の使い分けは行われていないことにご注意ください。


□みんな画面設計ってやってる?

「画面仕様書」や「画面定義書」や「画面設計書」という言葉は世の中でもよく使用されている言葉です。しかし、実際のところ、これらはあまり明確に使い分けら れていないように思います(少なくとも私の周りでは)。これらは私の知る限りでは、先ほど言葉として定義した「画面仕様」を定義するためのドキュメントで す。

一方、先ほど言葉として定義した「画面設計」を定義するためのドキュメントは、通常は作成されません。強いて言うなら、クラス設計書などが一番近いでしょうか。しかし、これもプロジェクトの多くでは共通部分などの重要な部分に絞って作成される程度であり、またアプリケーションレベルの画面に特化して作成するとなるとさらに少なくなります。

このように「画面設計」のためのドキュメントが作成されないてこなかったのは、まずそもそも複雑でリッチな画面を作成することが少なかったということがあります。ゲームなど一部の業界を除くと、リッチな画面が求められるようになったのは比較的最近になってのことです。しかし、モバイル系やWeb系のアプリを中心としてリッチな画面を作成する必要性は増しているので、それに応じて画面設計が必要とされるケースも増えていくでしょう。

そして、この画面設計を目的としてMVVMパターン(より正確にはPresentation Modelパターン)を使用することができます。


□画面設計したいならMVVM

MVC などの他の画面アーキテクチャの場合、レイヤの分けが、画面自体の抽象ではなく、画面を構成する機能の分担となっています。このため、VやCといった単位であっても個別にみてみれば実装レベルのものしかでてきません。無理に画面設計らしいものを作ろうとしても、むしろ画面を実装しながら作成したほうが良い ようなXML Documentationと大差ないものになるのが関の山でしょう。

しかし、MVVM(より正確に はPresentation Model)のViewModelは、画面自体を抽象化した画面モデルです。また、画面仕様が存在すれば、画面の実装に先だって作成することができます。 こうしたことからViewModelのクラス図は画面設計として扱うことができるのです。

この画面設計を行えるという利点は、ある種のプロジェクトではMVVMを採用する強い動機となり得えます。


□Eclipseプラグイン開発をしていた時の経験

以前私は、Eclipseのプラグイン開発を行っていましたことがあります。画面仕様もリッチで、かつ実装もそれなりに大きなものでした。画面のための共通 ライブラリを作成して、そこではドキュメント化を行ったものの、それを使用して作成される個々の画面では、画面設計らしいものは何もなくただ巨大なコード の塊があるのみでした。

画面の共通ライブラリによって実装をガイドとする方針でしたが、それでも画面を実装した人に 任される部分も多く、画面実装が開始されてしまうとそこから先はブラックボックスとなり、他の人は手を出すのが難しい状況となりました。開発から保守の フェーズに移行するタイミングでソフトウェアを引継ぎきましたが、お世辞にも引き継いだといえるようなものでありませんでした。

こうしたことはリッチな画面だから仕方がないのだと当時は思ったものですが、現在では「MVVMを使っていれば」と思うことがあります。MVVMであれば、画面のための共通フレームワークの構成も異なるものであっただろうこと、ViewModelのクラス図を使っ てレビューもかけて品質と実装の均一化を担保できたであろうこと、画面開発のスキルの展開も容易であっただろうことを想像します。

MVVMでの、ViewModel設計をしっかりと行うことで、ソフトウェア品質と保守性の向上に役立ちます。


Eclipseプラグイン開発はモデリングを中心としている

ちなみに、MVVMはWPFやSilverlightの技術ではありますが、MVVMがベースとしているはPresentationModelや Application Modelと呼ばれるパターンです。私がEclipseプラグインの開発していていたころにはまだ存在しなかったのですが、実は次世代のEclipseにもこれらのパターンが導入された「Modeled UI」と呼ばれる技術が存在します。

実はEclipseのプラグイン開発の世界は、そもそもモデリングがとても重視されている世界であり、モデル化のためのライブラリがとても充実しています。私がプラグインを開発していた当時はMVVMのような汎用的な画面自体のモデリングは(たぶん)なかったものの、UMLツールのようなグラフィカルなツールを作成するライブラリや、その他多くのライブラリがモデルをプラグインして拡張されることを当たり前としていました。そして、Modeled UIと呼ばれる技術も、比較的モデリング色が強い技術となっています。Eclipseプラグイン機構自体が巨大なDSLとメタモデルをプラグインしていくための基盤のようなものであり、そしてUI自体も複雑になりがちなので、当然のようにモデリングが中心となっているのです。

このときの私の経験はMVVMでの開発にも生かされました。

WPF/Silverlightのデータバインドやその他の技術は、EclipseやJavaが持つ技術に比べるととても強力です。使いこなせばMVVMを強力にサポートしてくれます。しかし私が初めてMVVMを勉強したとき、足元をすくわれたのもこれらの技術でした。たくさんの技術にばかり目を奪われて方向性を見失い、結局のところどうしてよいのか分からず途方に暮れてしまったのです。
 
この時に、Eclipseプラグインでのモデリングの経験が役に立ちました。ViewModel(Presentation Model)をしっかりとモデル化する道をとることで、これら技術をどこで使うべきなのかをガイドしてくれるようになったのです。

そして、ViewModelのモデリングは、Eclipseのような手厚いモデルのためのサポートがなくてもあまり問題にならないこともこのとき分かりました。(ただし、何かViewModelを生成するような仕組みがあったほうが便利ではあります。自分のプロジェクトでもViewModelの自動生成の機構は開発しています。)

ViewModelのモデリングなしでは今でもMVVMで途方に暮れていたことは容易に想像できます。モデリングによるUIの開発はEclipseでの専売特許ではありません。WPF/Silverlightはモデリングのための技術が薄いですが、それでも全体的にはMVVMのための手厚い技術が存在しており、むしろEclipseよりも適しています。


□[原則3]ViewModel設計を画面設計に位置づけ積極的に設計すること

MVVMは画面設計を行うことができるUIアーキテクチャです。プロジェクトの性質によっては、採用の大きな動機となり得ます。ViewModel設計をしっかりと行うことで、ソフトウェア品質と保守性の向上に役立ちます。

ViewModelをしっかりとモデリングすることで、MVVMの技術に振り回されず、これらを支配下においてください。MVVMの本質は画面のモデリングであり、そしてViewModelの設計であるといっても過言ではありません。

[原則3]ViewModel設計を画面設計に位置づけ積極的に設計すること

これで、今回のブログは終了です。長文お疲れ様でした。
これまでの説明ではViewModel設計の位置づけ的なお話が多かったと思いますが、次回以降では、よりViewModelの設計方法について説明していきます。技術者にとっては次回以降の方が読んで楽しいかもしれませんね。ご期待ください。

以上。

人気の投稿