Progression で MVC的なサムシング (2)

ProgressionでMVC的にプログラム書こうと色々やってたら、全然関係ない切り分けパターンになってきたよ、の話。
その２。

MVCの「M」にとり憑かれる

ProgressionでMVCっぽく、という事を考えると、行き詰るのは、
「・・・で、ダレをModel(アプリケーションのデータ)として扱うの？」という疑問でした。

Progressionの場合

公式ガイドに沿ってクラススタイルでコードを書いていくと、SceneObjectを中心にコンテンツを組んで行く事になると思います。
自分の場合もそれに倣って、SceneObjectを香盤表のようにしてコードを書くようにしてます。

そういうスタイルでやってると、どうにもこうにもMVC的な構造が作りづらいなー、と思ってました。
いや、構造が作りづらい、というより、だれがModelなのかが解からないから、切り分け方が解からない、みたいな感じかな。

具体的に困った場面は、あるシーン以下で、共用したい外部画像データがある場合でした。

具体例 （一般的な galleryコンテンツ）

例えば、こんな感じで、ギャラリーコンテンツを作ろうとしたとします。

ギャラリートップで、XMLを読み込みます。そのxmlに書いてあるサムネイル画像のURIを元に画像をロードして、表示します。さらに、サムネイルの数だけgallery detail sceneをnewして、ギャラリートップシーンにaddSceneしますよ、と。
detail sceneでは、大きな画像をロードして表示しつつ、サムネイル画像をランダムに２０個選んで表示しますよ、と。

ここで、MVCに憑かれてた僕としましては、画像URI情報の取り回し、どうするよ？という風に考えるわけですね。（ほとんどビョーキですねー）

detail sceneをnewする段階で、引数で必要な画像パスを渡したらいいんですけど、それってMVC的ではないよなー、と。

それ以上に、「無作為に２０個選んで画像表示する」というクダリでは、同じシーンに複数回到着した時にも、毎回ランダム抽出しなきゃ要件満たせないわけなんで、引数で渡しちゃうとダメですよねー。

詰まるところ、SceneObjectとは無関係なところで、画像URI達を保持して、適宜引き出す（getする）必要があるのかなー、と。

で、色々な本を参考にして、MVCっぽくクラス構造を考えては試してみて、をやってみたものの、どーもシックリこない。
シックリ来ないっていうのは、どの方法も、Progressionの機能を活かした状態で、MVCっぽくできてない、って事です。

ここで、結構な暗礁に乗り上げた感がありました。

で、MVCを忘れて、オレオレ・パターン

で、MとVとCのことは、一旦忘れることにしました。
可能な限りデータ層とそれ以外で切り分ける事に集中してみましょうよ、と。

gallery コンテンツでは、「画像URIのデータをどう共有して、どのタイミングで必要な情報を引き出すか」が問題であるわけですよね。

で、幾つかの試行錯誤をした結果、ワタシが一先ず考えたのはこんな感じ。

Progression的にはやっぱりSceneObjectに”Castをアド”とか書くのが一番解かりやすい気がするので、データを共有する場合も、SceneObjectを介して共有するのが良さそうかな、と。

さらに言えば、そのデータが要らなくなるタイミングも、Gallery Scene のatSceneUnloadで掴めるので、そこでデータを明示的に破棄すれば、アプリケーションとしてのメモリ節約にもなりそうですし。

今回は親シーンと子シーンの問題でしたけど、この方法なら、直接親子関係にないSceneObject間でも共通データを
共有することは簡単にできそうですね。

個人的に目からウロコだった、というか、アハ体験だったのは、protected static っていうアクセス制御。（図では、Abstract Gallery Scene　の imageURIs と getRandomPath）
これで、スーパークラスが同じでさえあれば共通データに簡単にアクセスできるんですねー。
protected static、クラス設計の定石なのかもしれないですけど、自分はなかなか気づけませんでした・・・orz

で、再度MVCを考える

ここで、再度MVCを考えてみます。

色々と本を見てると、例として上がるのは「時計表示の仕組み」だったり、「ラジコンカーを操作する仕組み」だったり、アプリケーションというよりは、説明のために「ある機能の一部」を切り出したものばかりなので、ついつい、それくらいの小さな単位で考えなければならないような気がしてたんですが、実際は、もっと大きなところで考えなければならないのかもしれないなー、と。

今回の例で言えば、「ギャラリーコンテンツ」という単体アプリケーションであると考えれば、アプリケーションとして取り回さなければならないデータが何なのかは、自ずと絞られる気がします。

今回は画像URI達を「アプリケーションに必要なデータ」として扱ってみたんですが、これ、実際はURIじゃなくても、ロードしたBitmapDataでもいいわけですよね。共用さえ出来てれば。
もっと言えば、ロードした画像をアサインしたCastBitmapでもいいわけですし。

「いやいや、それはView要素だろう」、という気もしますけど、そこは柔軟に考えて、「表示要素すら、情報（データ）だ」と考えれなくもないわけですし。（ちと強引？）

結局のところ、何をデータとして扱うのかを決めるのは、どういうアプリケーション（機能）を作成（実現）したいのかに依存するって事なんでしょうかね。

FlashコンテンツをProgressionで作ってると、「このシーン以下は、ギャラリーコンテンツ」、「このシーン以下は、ゲームコンテンツ」とか、シーン単位で、個別のアプリケーションが作られる場合が殆どな気がします。

なので、１つのswfで１つのMVC構造を作る、という心構えではなくて、このシーン以下はこういうアプリケーションだから、SceneObject経由で共用するデータはコレかな、くらいの感じで、今回の方法で作っていくと、Progressionのオイシイところを享受しつつ、データだけはSceneObjectに隔離できてハッピーなのかもしれません。

まとめ

なんか、長々と書きましたけど、結局記録しておきたかったのは、

スーパークラスにあるprotected static なヤツには、サブクラスから一意にアクセスできますよって所だけでしたw

以上、MVCなんて殆ど知らない不肖ワタクシが、勝手に色々難癖つけながら書きました。　きっと、ツッコミ所が満載だと思います。
なので、「おいおい、そこは違うだろ、ヴォケが」という箇所があったら、是非教えてください。

あと、画像でなんちゃってUML図を描いてますが、そこへの突っ込みもお待ちしております。

追記

一度くらいは、ガッツリMVCな感じでFlashを作るべきな気がするので、その時に使うと良さげなFrameworkをメモ。
PureMVC
flashMVC