Mediatorパターンについてまとめてみた

2010 年 3 月 31 日nishigo

みなさんこんにちわ、最近は春の訪れがやってきてるとは思えないほど寒空でしたが、
道ばたにタンポポも咲き始め、花見が楽しみなシーズンになってきましたね。
「さまざまのこと思ひ出す桜かな」
なんて芭蕉の歌を書いてみると、一人で桜を見て思い耽るのも悪くないかなと感じてしまうnishigoです。

さて、今回はGoFの23のパターンの中のMediatorパターンに焦点を合わせます。
オブジェクト指向でモデリングをすると、必然的に多数のオブジェクトに分割され、それらの間が（メソッドを経由した）メッセージでつながることになります。

オブジェクト数が増えると、メッセージの通知先が増えることになりがちです。その結果、オブジェクトどうしが複雑に絡み合う状態となってしまい、メッセージがどの順にどこへ流れるのかが分かりずらくなってしまいます。

この問題を解決する手段として、Mediatorというパターンが役に立ちます。
Mediator（仲介者）という名の通り、各オブジェクトの仲介をするオブジェクトを間に置いて、オブジェクト間のつながりを整理します。

単純な例として、Person（個人）とGroup（グループ）というクラスを考えます。PersonとGroupは多対多の関係が成立するものとします。
つまり、Groupに複数のPersonが所属すること（これは普通）も、Personが複数のGroupに所属することもあるものとします。

所属関係が成立するPersonとGroupの関連付けの方法として、リンク（参照）を張るという方法は

単純で分かりやすい方法です。しかし、リンクの数が増えやすい（PersonとGroupのオブジェクト数の積の半分）という問題があります。

オブジェクト図

そこで、両者の間にMappingというMediatorクラスを置くことで、このリンク数を減らします。Person, Groupの各オブジェクトはMappingのオブジェクト（以下、Mediator）だけとリンクを張ります。

ちょうど、車輪のハブのようにMediatorを中心にして、各オブジェクトはMediatorを経由して、他のオブジェクトとつながります。

各PersonはMediatorに接続するときに、自分が所属するGroupの一覧をMediatorに通知して、その対応関係はMediatorが保持します。
こうすることにより、GroupオブジェクトがMedeiatorに自分に所属しているPersonオブジェクトの一覧を取得するときは、Mediatorは保持している対応関係表からPersonのオブジェクトをGroupに返します。

この構成を取った場合、オブジェクトはMediatorと1:1に対応するため、オブジェクト数が増えたとしても、リンクの数が加速度的に増加することはありません。

この構成のMediatorが、各オブジェクトの通知手段の機能を持つようになると、同じくGoFのObserverパターンとなります。

Observerパターンの場合、それぞれのオブジェクトは自分がリンクを張っているObserver（通知手段を持ったMediatorオブジェクト、以下同じ）へ通知（イベント）を送信します。
それを受け取ったObserverは他のオブジェクトへその通知（イベント）を転送することで、メッセージを通知します。

Obserberパターン

典型的な例としてはウィンドウシステムにおける、ウィンドウとウィンドウマネージャの関係があります。
ウィンドウは自分のウィンドウの描写内容のアップデートが必要なったときに、Observerであるウィンドウマネージャに、画面描写のアップデートの要求を通知することで、他のウィンドウの状態を確認しに行き、最終的な画面を描写します。

[シーケンス図]Mediator