一。仲介者パターン
仲介者、つまり第三者で、本来は双方が直接交互するところを、仲介者を導入した後、すべての交互は第三者を通じて完成させる必要があります
例えば、もともとはトランシーバーで直接通信していたのが、今はメールに変わり、メールサーバーが転送を担当します。モジュール交互に対応すると、もともとの網状構造が今は星状構造になり、各モジュール間の依存が低減され、中心点(仲介者)に統一して依存し、同時に中心点もこれによりより多くの制御権限を獲得しました。例えば、一斉送信、バブル通知などが可能です
すべてのモジュール間の交互は仲介者を通じて行う必要があり、モジュールは互いにあまり詳しくありません。メッセージを仲介者に発行するだけで、仲介者は自然に知情が必要(対応するテーマを購読した)人に通知します。システムはこのメカニズムで動作し、仲介者が制御核心です
二。仲介者パターンの具体的実装
###1. 最も簡単な仲介者パターン
var mediator = (function() {
var topics = {},
subUid = -1;
var publish = function(topic, args) {
if (!topics[topic]) {
return false;
}
var subscribers = topics[topic],
len = subscribers ? subscribers.length : 0;
while (len--) {
subscribers[len].func(topic, args);
}
return true;
};
var subscribe = function(topic, func) {
if (!topics[topic]) {
topics[topic] = [];
}
var token = (++subUid).toString();
topics[topic].push({
token: token,
func: func
});
return token;
};
return {
publish: publish,
subscribe: subscribe,
// 好像确实没有比 installTo 更合适的名字
installTo: function(obj) {
obj.publish = publish;
obj.subscribe = subscribe;
}
}
}());
// 具体应用
var mod1 = {
run: function(arg) {
console.log('mod1 received ' + arg);
}
};
var mod2 = {};
var topic = 'myTopic';
mediator.installTo(mod1);
mediator.installTo(mod2);
// mod1 订阅消息
mod1.subscribe(topic, function(t, arg) {
mod1.run(arg);
});
// mod2 发布消息
mod2.publish(topic, 'data');
一見すると前面で紹介した [発行/購読パターン] とあまり違いがありません。例に現れる一つの違いは、どのモジュールもメッセージを発行できることで、発行/購読パターンでは観測者は受動的にメッセージを受信するのみです。具体的な差異は以下で詳しく展開して紹介します
###2. 機能が強大な仲介者パターン
http://thejacklawson.com/Mediator.js/index.html は機能が強大な実装を提供し、topic 名前空間、メッセージバブル、優先度などをサポートしています
ソースコード(注釈付き)はhttp://thejacklawson.com/Mediator.js/mediator.html、または github を参照
三。仲介者パターンと発行/購読パターン
(もちろん、発行/購読パターンは観測者パターンに由来し、仲介者パターンは孫世代と言えます。)
実装から見ると、仲介者パターンと発行/購読パターンは非常に似ており、注意深く見ないと差異に気づかないほどです。主な違いは以下の通りです:
- 通信方式
仲介者パターンでは各モジュールがメッセージを発行でき(仲介者自身もメッセージを発行可能)、発行/購読パターンでは観測者は受動的にメッセージを待つことしかできません
- モジュール依存構造
仲介者パターンは星状構造で、仲介者は一つの*「制御点」であり、発行/購読パターンでは、発行購読メカニズム自体は一つの「制御層」*であり、上位層は制御層を通じて下位層モジュールを操作できることを意味します(上位層は仲介者を通じて下位層モジュールを制御することもできますが、これは星状構造の本意ではありません)
- 情報発行方式
多対多から多対一になり、すべてのモジュールは仲介者と直接対話することしかできません
欠点:
- 単一故障点
これは仲介者パターンの最大の欠点で、発行/購読パターンにもこの欠点は存在しますが、仲介者パターンではより鋭く現れます(「制御点」と「制御層」を組み合わせて理解)
- パフォーマンス低下
モジュール間は第三者を通じてのみ交互でき、直接交互と比較して確実にパフォーマンス低下が存在し、デザインパターンの共有する副作用です
- ロジック実装の難度増加
疎結合によりシステムが制御しにくくなり、ブロードキャストのみを注目するだけでシステムがどのように反応するかを確定するのは難しく、完全なロジックを各 Topic に分割する必要があり、実装上の複雑さが増加します
参考資料
- 《JavaScript デザインパターン》
コメントはまだありません