Mediator パターン再履修(6) ～組んでみての雑感～
2010/05/16 16:14 - AS3.0
前々回は Colleague、前回は Mediator と各クラスのコード実装を見てみましたが、それらを組み合わせて実際に組んだものは↓
今回は Mediator パターンを使って、そこそこ複雑なプログラムを組んでみた雑感をば、つらつらと書き綴ってみたいと思います。
好感触な点
MVC の分割に悩まずに済む
プログラムの機能ごとにクラスをけっこう細分化するので、どの機能は Model 組み込むか、どの機能は Controller に組み込むか…… と迷わずに済むなぁ、って感じ。
特に、ユーザ入力のために使用される表示物が、View なのかそれとも Controller なのか、未だに迷い続けている私としては、そういうことに悩まされずに済むというのは非常にありがたい。
ところで前々回 Colleague のコードを組んだとき、Mediator との通信パターンで以下の三つに分類できそうだ、ということを見ました。
- Mediator から通告されるだけ
- Mediator に申告するだけ
- 相互通信あり
これって、MVC に対応してんのかなぁ。以下みたいな感じで。
- View（ExBitmap クラス）
- 未だに View なのか Controller なのか迷い続けているユーザ入力用表示物（ExPushButton クラスと ExHSlider クラス）
- Model（FileRefUnit クラスと ImageProcesser クラス）
で、Mediator は Controller である、と。
未だに悩んでいる 2. を View だと認識すると、MVC の悩みが解消するなぁ。
分かりやすさ
各 Colleague がどのように協働するのか、ということを Mediator クラスに、しかもその中でも notify メソッドだけに詰め込むというピンポイントぶりが、とっても分かりやすいんじゃないでしょうかね。
デバッグが必要になったときに、基本的に Mediator.notify だけ見ればイイんだからチョー楽チンでしょう。
疑問点
ドキュメントクラス
ところで Mediator クラスは Controller なんだそうですが、これってわざわざ単独のクラスとして生成しなけりゃいけないもんなんすかねー？
Mediator 内で Colleague 生成してるんだし、独立したクラスじゃなくって、ドキュメントクラスに肩代わりさせても良いんじゃないのかなぁ。
でも java にしても C++ にしても解説本なり実際のコードなりを読んでみると、ドキュメントクラスってこんな感じで、ほとんど何もしない使い方してるんすよね。
共用データの場所
今回、Colleague は 完全に孤立させ、Mediator とのみ通信し、他の Colleague とは一切関係を持たない、ということにこだわったので、複数のクラスが共用するデータを Mediator が保持するようにしました。
でも MVC 理論ではそういうデータは Model が持つことになってますよね。
そうすると今回のプログラムで設定した Mediator.bitmapData とかは Controller である Mediator ではなくて、Model に相当すると想定される ImageProcesser または FileRefUint に保持するべきなのかなぁ。
そうすると Colleague の通信相手は Mediator だけ、という原則が崩れるんですよね。
あと、Mediator パターンのアキレス腱である協働ロジック記述（Mediator.notify）部分をもうちょっとスッキリ分かりやすくできないかなぁ、と思っていたら、さらなる情報を発見した！
続く。
シリーズ
- Mediator パターン再履修(8) ～Cocoa 風作法(2)～
- Mediator パターン再履修(7) ～Cocoa 風作法(1)～
- Mediator パターン再履修(5) ～Mediator～
- Mediator パターン再履修(4) ～Colleague～
- Mediator パターン再履修(3)
- Mediator パターン再履修(2)
- Mediator パターン再履修(1)
