PACをなるべく簡単に実装したい

ここで、自分的にPACのそれぞれの役割をまとめてみる。

Presentation

  • UI
  • ユーザーの入力を（必要であれば）Controlに渡す

Control

  • 他エージェントと連携するのに必要な機能を司る、つまり、
    • 外部から参照する自エージェントの状態保持
    • 上位エージェントへのメッセージング
  • 自エージェント内でのPresentationとModelの仲介

Abstraction

  • エージェント内の主な機能のロジックとデータを司る


ここから、各部分間の関係について実装面から考えてみる。

P(Presentation)-A(Abstraction)

AのデータをPに反映させるのが唯一求められること。こういうのはよくObserverパターンが用いられる。
ASではデータバインド機構があるのでそれを使わない手はない。

しかしPACでは、PとAの間のやり取りは認められてない。だがせっかくバインド機構があるのに手間はかけたくない。
ということでPACから外れて、やっぱり上のようにする。


こうなると本当はPACよりHMVCというので紹介されたパターンになる。
http://www.javaworld.com/jw-07-2000/jw-0721-hmvc.html
HMVCはHierarchical-MVC（階層MVC）のことで、MVCをPAC化したようなものになっている。

この記事は詳しく書かれていてタメになると思う。

A-C(Control)

AのデータはバインディングでPへ渡すとしたので、AからCへはMVCのM-Cと同じく基本的に何もすることはない。ただし他エージェントとのやりとりはCでするため、例えばAでの処理の終了が外部の動きにも関係する場合は、処理終了をCに知らせる必要があるだろう。これは（P-Cと同じく）イベントの送出で実装した方が依存しなくていいだろう。

CからAは、Cで何かイベントを感知した時（Pからのイベントや外部からの呼び出し）に、Aを操作できればいい。これは普通にCからA（のインスタンス）のメソッドを呼ぶことでいいだろう。

P-C

PからCへはユーザーからの入力を伝達する。（そして必要に応じて外部やAに伝達される。Pから-Aに直接ユーザー入力を教えてもいいが、外部エージェントに関係する入力もあるだろうから、Cを経由するルールにする）

CからPはMVCのVCと同じく何もすることなし。だが、PACではCが全ての起点になるため、実際にはControlオブジェクトからPresentationインスタンスを生成しないといけない（Abstractionインスタンスも同様）。

よって、なるべく依存性をなくす形を取るために、Controlオブジェクト内にPresentationインスタンスを持つのは仕方ないとして（DIとかFactory用に余計なクラスを作らない）、Presentationからはイベントを送出してControlはそれをキャッチすることにする。