Mediator パターン再履修(2)
2010/05/11 21:36 - AS3.0
前回、Mediator パターンを調べたときは Obsever パターンとの違いがよく分からなかったんですが、それは複数の Colleague が単一クラスの事例だったせい。 Mediator パターンが本来の力量を発揮するのは、Colleague がいろいろなクラスの混成部隊のときなんですね。
ってなわけで、再履修を始めるにあたって、本来の Mediator パターンの使われ方について、ちゃんと見てみますよ。
参考書は←
「Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本
Madiator パターンは以下の2種類のクラスによって構成されるパターンです。
- 周囲に影響される有象無象（Colleague）
- その有象無象に指示を与える司令官（Mediator）
Colleague（同僚）はそういう名のクラスというよりも、Colleague としての interface を備えた各種クラス群。
この有象無象はそれぞれの仕事を受け持ちますが、他の Colleague の状態・状況などに影響を受ける場合があり、しかも各 Colleague によって、影響を及ぼす相手 Colleague やその数、影響の内容などが異なったりします。
このようなとき、Colleague 同士を連携させる設計にすると、各 Colleague 内で相手 Colleague の判定やその反応などを記述しなければならなくなるため、すぐに破綻することになるでしょう。
そこで登場するのが、たったひとりの冴えた Mediator。
Mediator パターンでは、Colleague 同士が直接情報をやり取りすることを禁止し、Colleague からの申告は Mediator だけが受けつけます。
そして Mediator は、ある Colleague から申告があった場合、その影響を受ける他の Colleague にその旨を通達します。
このように Colleague は自分の職務に専念し、Mediator は全 Colleague たちが、どのようなときにどのように動くのかということをくまなく熟知する必要があります。
その結果、Colleague は単機能な部品となり再利用が容易になります。また Mediator はそのプログラムでのシナリオが記述された、そのプログラム専用の部品となるため、再利用はできません。
つまり、もっぱら Mediator のロジックにさえ注意していれば良いというパターンですね。 また、Mediator のロジックはゴチャゴチャになりやすいから気をつけろ、ってことでもあります。
以上を踏まえて、画像ファイルを読み込んでコントラストを調整し、その画像をセーブできるプログラムを Mediator パターンを使って組んでみます。
相互通信のため Mediator と Colleague はそれぞれ相手との窓口として public なメソッドを備える必要がありますが、今回はそれぞれ以下のようにします。
- Colleague から呼び出される Mediator のメソッド
- Mediator.notify();
- Mediator から呼び出される Colleague のメソッド
- Colleague.update();
続く。
シリーズ
- Mediator パターン再履修(8) ～Cocoa 風作法(2)～
- Mediator パターン再履修(7) ～Cocoa 風作法(1)～
- Mediator パターン再履修(6) ～組んでみての雑感～
- Mediator パターン再履修(5) ～Mediator～
- Mediator パターン再履修(4) ～Colleague～
- Mediator パターン再履修(3)
- Mediator パターン再履修(1)
