在《JavaScript設(shè)計模式》關(guān)于中介者模式的介紹里，里面有些錯誤和擅自添加的例子爷光，雖然例子（英文版沒有）是為了讓人更好理解御吞，但是該篇章加上的例子卻給人誤導(dǎo)的感覺，所以如果有人讀這個章節(jié)時腌紧，建議看英文版。
在看這個模式時候畜隶，我只想弄明白一點壁肋，中介者模式與訂閱/發(fā)布模式的區(qū)別在哪？
中介者（Mediator）模式定義
中介者作為一種行為設(shè)計模式籽慢，它公開一個統(tǒng)一的接口墩划，系統(tǒng)的不同對象或組件可以通過該接口進行通信。增加一個中介者對象后嗡综，所有的相關(guān)對象通過中介者對象來通信，而不是互相引用杜漠，所以當一個對象發(fā)生改變時极景，只需要通知中介者對象即可。
英文版：
When it comes to the Mediator and Event Aggregator patterns, there are some times where it may look like the patterns are interchangeable due to implementation similarities. However, the semantics and intent of these patterns are very different.
And even if the implementations both use some of the same core constructs, I believe there is a distinct difference between them. I also believe they should not be interchanged or confused in communication because of the differences.
中文版：
它也可能被認為是額外的或者是用于應(yīng)用程序間的通知驾茴，如不同子系統(tǒng)之間的通信盼樟，這些子系統(tǒng)本身就很復(fù)雜，且可能希望通過發(fā)布/訂閱關(guān)系實現(xiàn)內(nèi)部組件間的解耦锈至。
我：
首先我是不明白譯者為什么不按英文版翻譯晨缴，另外還有一點譯文的意思根本就不是英文版的意思，我覺得不對峡捡。
我覺得是——中介者模式與事件訂閱模式有些時候看起來是可以互相替換的击碗，因為它們的實現(xiàn)都差不多筑悴，但從語義和意圖上講，這些模式是各不相同的稍途。即便是實現(xiàn)都用了相同的核心結(jié)構(gòu)阁吝，我相信他們之間還是有區(qū)別，在通信時是不能互換和混淆械拍。
PS：總結(jié)就是突勇，兩個模式實現(xiàn)上有些相同，但意圖是不同的坷虑。
例子
簡述：
機場交通控制系統(tǒng)甲馋。控制塔處理飛機的起飛和降落迄损，所有的通信都是控制塔控制的定躏。
//飛機
var Plane = function(name){
this.name = name;
}
Plane.prototype.takeOff = function(){ //起飛
ControlTower.takeOff(this);
}
Plane.prototype.sendMsg = function(toPlane, msg){ //飛機間發(fā)消息
ControlTower.sendMsg(this, toPlane, msg);
}
Plane.prototype.receive = function(fromPlane, msg){
console.log(this.name + "-收到來自-" + fromPlane.name + "消息:" + msg);
}
//飛機控制塔(中介者)
var ControlTower = (function(){
//假設(shè)只有一條跑道，跑道只能起飛一只飛機（不說降落）
var onTrackPlaneName,
canTrackUse = true;
var takeOff = function(plane){
if(!canTrackUse){
console.log("跑道正在使用中...");
return;
}
if(onTrackPlaneName == plane.name){
console.log("您正在起飛中...");
return;
}
canTrackUse = false;
onTrackPlaneName = plane.name;
console.log(plane.name + "正在起飛中...");
setTimeout(function(){
canTrackUse = true;
onTrackPlaneName = null;
console.log(plane.name + "已起飛...");
}, 5000);
}
var sendMsg = function(from ,to , msg){
to.receive(from, msg);
}
return {
takeOff : takeOff,
sendMsg : sendMsg
}
})();
var p747 = new Plane('波音747');
var p666 = new Plane('飛豹666');
p747.takeOff();
p666.takeOff();
p747.sendMsg(p666, '開完飛機吃個飯么');
適用場景
1. 一組定義良好的對象海蔽，現(xiàn)在要進行復(fù)雜的通信共屈。
2. 定制一個分布在多個類中的行為，而又不想生成太多的子類党窜。
可以看出拗引，中介對象主要是用來封裝行為的，行為的參與者就是那些對象幌衣，但是通過中介者矾削，這些對象不用相互知道。（迪米特法則的具體實現(xiàn)）
優(yōu)點
1. 中介者模式能夠?qū)⑾到y(tǒng)中對象或組件之間所需的通信渠道從多對多減少到多對一豁护。
- 符合迪米特原則哼凯。
迪米特法則（Law of Demeter）又叫作最少知識原則（Least Knowledge Principle 簡寫LKP），就是說一個對象應(yīng)當對其他對象有盡可能少的了解,不和陌生人說話楚里。
缺點
1. 中介者模式的缺點是顯而易見的断部，因為這個“中介“承擔了較多的責任，所以一旦這個中介對象出現(xiàn)了問題班缎，那么整個系統(tǒng)就會受到重大的影響蝴光。
中介者模式與觀察者模式差異
1. 調(diào)度中心不同。
中介者模式調(diào)度是由中介者达址，而觀察者模式調(diào)度的是觀察者蔑祟；
中介者模式與訂閱/發(fā)布模式的調(diào)度方式更像，都是獨立一個集中的調(diào)度中心沉唠。
- 中介者模式參與了對象行為的實現(xiàn)（例如上面示例的飛機起飛）疆虚，而觀察者模式并不參與，僅做目標通知。
中介者模式與訂閱/發(fā)布模式差異
- 中介者模式與業(yè)務(wù)相關(guān)径簿，訂閱/發(fā)布模式與業(yè)務(wù)無關(guān)罢屈。（這是我覺得最大差別）
雖然實現(xiàn)結(jié)構(gòu)非常相像，但是很明顯的是牍帚，中介者模式參與業(yè)務(wù)相關(guān)東西儡遮，所以內(nèi)容是大相徑庭的。
2. 兩個模式都有集中調(diào)度效果暗赶，對象之間不直接參與通信鄙币。
參考文獻
1. 《Learning JavaScript Design Patterns》 by Addy Osmani
https://addyosmani.com/resources/essentialjsdesignpatterns/book/
2. 《JavaScript設(shè)計模式》by 徐濤【譯】
本文轉(zhuǎn)載至http://www.cnblogs.com/lovesong/p/5575594.html
