Mediator パターン (前編)
2009/01/04 19:27 - デザインパターン
久しぶりにデザインパターンの話。
今回は Mediator パターンについて。 まずはサンプルを見ていただきましょうかね。
見てのとおり、正方形のステージに5×5=25個の正方形のボタンをタイル上に配置したものです。
で、これらのボタンは、連続して同じボタンを押せないようにしたい。 一度押されたらどれか別のボタンが押されるまではボタン機能を停止する、そして現在そのボタンが選択中であることを示すために色を変えたい。 つまりボタン25個一組で一つのトグルになっているとでも申しましょうか。
そういうプログラムを組みたい場合、まず以下のような Main と Button の組み合わせが考えられますね。
今回のサンプルではすべてのボタンが同じ機能になります。 ということは、ボタンインスタンスを配列に格納して管理して、マウスイベントリスナーをドキュメントクラスから stage に登録する手法が採れます。 各ボタンインスタンスにではなくて。
で、問題なのはそのマウスイベントリスナーのコードです。 以下にその部分を抜き出します。
ボタンをステージ全体に配置しているので別に2行目は必要ないんだけど、まぁ一応書いておきます。次からが本題。
4～11行目で、配列に格納したボタンインスタンスの総当たりを実行してます。
総当たりで何をするのかというと、まず、配列のカレントボタンインスタンスと、マウスイベントリスナーから送られてきた target、つまり今押されたボタンが一致するか否かのチェックをおこないます（6行目）。
一致したボタンインスタンスは、今押されたボタンなので、ボタン機能を停止させます（7行目）。
一致しなかったボタンインスタンスは enabled プロパティをチェックします。 enabled プロパティが false のものは、前回押されて今まで機能を停止していたボタンなので、ボタン機能を復帰します（8行目）。
間違いじゃないけどムダが多いですよね。
処理のために知らなければいけないのは、前回押されたボタンと、今押されたボタンの2個だけ。でもこのアルゴリズムでは25個全部をいちいち確認せにゃならぬ。
チェックするのが25個程度だからまだいいけど、これがもっと膨大な数になったら処理時間に影響を与えかねん。
そんなときに役に立つのが Mediator パターン。
では Mediator パターンの適用によりコードがどう変わるんでしょう。
後編に続く（キートン山田の声で）。
