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はそれをキャッチすることにする。
P/A/Cの役割revised
こうして実装面も考えると、各部分の役割は以下のようになるかと考えた。
Presentation
- UI
- ユーザー入力を内部イベントの送出によってControlに知らせる
- イベントによるため、Controlへの依存はない
Control
Abstraction
- エージェント内の機能のロジックとデータを司る
- 内部処理のイベント（処理の終了ぐらいしか思い当たらない）をイベントによってControlに知らせる
- Presentationと同じくContolへの依存はない
次はもっと実装レベルについて。
