この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
はじめまして、su10です。Flex向けのフレームワークであるPureMVCについて学んだことを自分なりにまとめて解説していきたいと思います。(2012/5/25更新)
■ PureMVCあるある
「うちはPureMVC使ってるから勉強しといてね」
「わかりました」
数時間後…
「（ネット上にわかりやすい説明ない…「Cairngorm」って何だよ…帰りたいよ…）」
こんなことってよくありますよね。自分の場合は「とりあえずコード読んだらわかるだろう」と思ったらhandleNotificationが一体何なのかわからず、目から汗をかきそうになりました。
■ PureMVCの基本
まずはPureMVCとは何か？最初に書きましたが、PureMVCはFlex向けのフレームワークです。Flex向けといってもJavaやC#向けもあるらしいので、これを機会に理解しておけば夢が広がります。そもそも「フレームワークってなに？」という人は「フレームワーク プリン」でググってもらうとして、まずは基礎となるMVCという概念の解説です。
Model、View、Controller
MVCはModel、View、Controllerの頭文字を取ったものです。プログラムの機能をこの３つに分けて書くことでコードがわかりやすくなります。MVCの考え方自体はRailsにもありますね。PureMVCでもこの考え方に基づき、コードを書いていくことになります。それぞれの機能は以下のようになっています。
- ・Model … サーバとのやり取り、データの管理、ビジネスロジック
- ・View … ユーザに見える部分の処理
- ・Controller … ユーザの入力などに応じてModelの機能を呼び出す
「ビジネスロジック」という単語がわかりにくいですが、要するに「ユーザに見える部分の処理とデータやデータベースの処理の間にある処理」のことです。流れとしては次のようになります。
- ユーザが入力を行う（View層が処理）
- 入力に応じてModel層の機能呼び出し（Controller層が処理）
- データの更新などを行う（Model層が処理）
- データを取得して見た目に反映する（View層が処理）
コアアクターとFacade（ファサード）
先ほど「○○層」と表現しましたが、実はPureMVCではクラスとしてModelクラス、Viewクラス、Controllerクラスが用意されていて、これら３つをまとめてコアアクターと呼びます。これらのクラスに先述のような機能をそれぞれ分けて実装していくと考えてください（実際には少し違いますが）。
また、Facadeというクラスが用意されていて、Facadeを通じてコアアクターとやりとりができます。もう少し具体的にいうと、Facadeクラスのインスタンス（もっと正確に言うとFacadeクラスを継承したサブクラスのインスタンス）経由でコアアクターの機能を利用することができます。つまり、実際にはコアアクターの３つのクラスをインスタンス化したり直接どうこうする必要はなく、コアアクターは互いを知らなくても良いのです。コアアクターに直接仕事を頼むのではなく、Facadeを通じて仕事をお願いするのです。こうすることでそれぞれのクラスの結合が疎になり、保守性が高まっています。大事なので何度も書きますが、
コアアクターはFacadeを通じてお互いの機能を利用できるので、お互いについて知っている必要はない
です。
いろいろ書いてきましたが、ここで重大発表です。実はコアアクターは先ほどMVCで述べたような仕事はしていません！（＼な、なんだってェー！！／）
実際にMVCで述べたような処理を行うのはProxy、MediatorとView Component、Commandと呼ばれるプログラムたちです。コアアクターの仕事はこれらを自分に登録し、管理することです。もちろん登録はFacade経由で行います。コアアクタークラスの仕事をまとめると、次のようになります。
- ・Model … Proxyを登録（Facade経由）し、管理する
- ・View … Mediatorを登録（Facade経由）し、管理する
- ・Controller … Commandを登録（Facade経由）し、管理する
また、Proxy、MediatorおよびView Component、Commandの役割は次のようになります。
- ・Proxy … Modelクラスに登録され、サーバとのやり取り、データの管理、ビジネスロジックを担当
- ・Mediator … Viewクラスに登録され、View Componentの管理、Notificationの送受信を担当
- ・View Component … Mediatorに登録され、ユーザの入力の受け取りと見た目の処理を担当
- ・Command … Controllerクラスに登録され、Notificationに応じてProxyを呼び出す
MediatorがViewクラスに管理されてさらにView Componentを管理しているというややこしい構造になっていますが、これについては次回説明したいと思います。
また、ここで初めて出てきたNotificationはイベントにも似た概念なのですが、これについても次回説明したいと思います。
ちなみに、Proxy、Mediator、View Component、Commandにあたるプログラムは当然たくさん必要になってきますが、それらを管理するコアアクタークラス、つまりModelクラス、Viewクラス、Controllerクラスはそれらを管理する大元の存在なのでインスタンスが一つしか必要ありません。Facadeクラスもです。よってコアアクターとFacade（を継承したクラス）のインスタンスはプログラムにただ一つだけ存在し、利用されます。このような「プログラム中に一つしかインスタンスがない」ことを保証するデザインパターンのことを「シングルトンパターン」といいます。また、私が参考にしたサイト（http://translated.by/you/puremvc-implementation-idioms-and-best-practices/into-ja/ (404 Not Found)）では「プログラム中に一つしかインスタンスがない」ことを指して「シングルトン」と呼んでいるので、以降はそのような意味で用いることとします。
それでは次回をお楽しみに。
