最近色々上位部分だけのスクリプティングなんかの仕事が多くて、そういったときにMVC的に作るとどーも効率が良くなくって「きー！」と叫ぶ毎日、如何に下層からダメージを食らわず、且つ的確に下層に情報を引き渡し、下層での自由度を保持して動作させるか？ということを模索してきて早１年、なんとなくMVCのコツみたいなのが分ってきた。（遅いなあ・・・ｗ）
下層にはVとCの機能限定版を使わせると結構効率が良い感じかな・・と。当然メインストリームとしてのMとCは存在しているのだけど（以下parentM,parentC）、V制御のためのMとC（以下childM,chikdC)をそれぞれのシーンに合わせたものを用意して連結してやると比較的負荷が分散される感じ。つまりOutputの場合はparentMからparentCがchildMを生成し、childCに引き渡す。VはそのchildCの命令に基づいて動作する。逆にInputの場合はchildCがchildVとparentCに指示をだし、parentMにフィードバックしつつVを制御。この辺classの中にも階層化構造を持たせてやるとデバッグの時のトレースも比較的楽なように感じる。
これによってある意味開発の作業分散化も可能。つまりparentCからchildMに引き渡すオブジェクト、またchildCからparentCに戻すオブジェクトさえ決まっていればその範囲内でchildはロジックを成立させることができるので、違う人が担当しても全然問題ないという感じ。
まぁこれ今一人でやってるんであんまり分散化のメリットとかはないのだけど、この方式で行けばロジックのセグメント化（ネスト化？）ができるんじゃないかしら？と思った次第であります。
まだ色々試行錯誤だけど、だんだんとObject指向の利点が見えてきた気がする。
同時にargmentは基本Objectベースでやり取りした方が引数の増減を吸収しやすいというのもちょっとしたコツかなあ・・・。
世の中のMVCと合ってるのかはわかりませんけど・・・。どーなんでしょう・・・？ってか元々これがMVCの考え方？と最後の最後でやっぱり不安になってみるｗ
－－－－－－－－－－ 山折 －－－－－－－－－－－
んーー。ちょっと見えたと思った瞬間再び雲の間に隠れてしまった・・・。
ロジックのセグメント化を基本に考えるとやっぱMへのchildCからのダイレクトアクセスってあまり望ましくない（デバッグの切り分けが難しくなるので）のだけど、そーなるとsetter,getterの効果があまり得られない。Objectをスーパーとした場合とかfor in でまわしたりするとmethodまで一緒に回ったりするのでなんか気持ち悪いなあということで、なんか意味もなくカスタムクラスインスタンスを生成して、それから他の変数に引渡し内容を継承するとかなんか無駄とも思えるような仕組みになる。
まぁ物によってはMovieClipに割り当てて、オブジェクト型に関係なく強制的に実行させてもいいような気もするんだけど、なんかそれじゃあふつーのファンクションと変わらねえような気もする。
あとは最近よく多次元配列ならぬ、多次元配列＊オブジェクト構造のデータセットをよくつかうんだけど、それをArrayに割り当てるべきかObjectに割り当てるべきがか悩んだりするｗ
（結局スーパーを設定しないで、単純なデータセットとして保持していたりするのだけど・・なにか不具合があるんじゃないか？と少し不安だ）