中介者模式

在我們生活的世界中，每個(gè)人每個(gè)物體之間都會(huì)產(chǎn)生一些錯(cuò)綜復(fù)雜的聯(lián)系。在應(yīng)用程序里也是一樣，程序由大大小小的單一對(duì)象組成，所有這些對(duì)象都按照某種關(guān)系和規(guī)則來(lái)通信。

平時(shí)我們大概能記住 10 個(gè)朋友的電話、30 家餐館的位置。在程序里，也許一個(gè)對(duì)象會(huì)和其他 10 個(gè)對(duì)象打交道，所以它會(huì)保持 10 個(gè)對(duì)象的引用。當(dāng)程序的規(guī)模增大，對(duì)象會(huì)越來(lái)越多，它們之間的關(guān)系也越來(lái)越復(fù)雜，難免會(huì)形成網(wǎng)狀的交叉引用。當(dāng)我們改變或刪除其中一個(gè)對(duì)象的時(shí)候，很可能需要通知所有引用到它的對(duì)象。這樣一來(lái)，就像在心臟旁邊拆掉一根毛細(xì)血管一般， 即使一點(diǎn)很小的修改也必須小心翼翼，如下圖所示。

面向?qū)ο笤O(shè)計(jì)鼓勵(lì)將行為分布到各個(gè)對(duì)象中，把對(duì)象劃分成更小的粒度，有助于增強(qiáng)對(duì)象的可復(fù)用性，但由于這些細(xì)粒度對(duì)象之間的聯(lián)系激增，又有可能會(huì)反過(guò)來(lái)降低它們的可復(fù)用性。

中介者模式的作用就是解除對(duì)象與對(duì)象之間的緊耦合關(guān)系。增加一個(gè)中介者對(duì)象后，所有的相關(guān)對(duì)象都通過(guò)中介者對(duì)象來(lái)通信，而不是互相引用，所以當(dāng)一個(gè)對(duì)象發(fā)生改變時(shí)，只需要通知中介者對(duì)象即可。中介者使各對(duì)象之間耦合松散，而且可以獨(dú)立地改變它們之間的交互。中介者模式使網(wǎng)狀的多對(duì)多關(guān)系變成了相對(duì)簡(jiǎn)單的一對(duì)多關(guān)系，如下圖所示。

在前面的圖中，如果對(duì)象 A 發(fā)生了改變，則需要同時(shí)通知跟 A 發(fā)生引用關(guān)系的 B、D、E、F 這 4 個(gè)對(duì)象；而在上圖中，使用中介者模式改進(jìn)之后，A 發(fā)生改變時(shí)則只需要通知這個(gè)中介者對(duì)象即可。

現(xiàn)實(shí)中的中介者

在現(xiàn)實(shí)生活中也有很多中介者的例子，例如機(jī)場(chǎng)指揮塔。

中介者也被稱為調(diào)停者，我們想象一下機(jī)場(chǎng)的指揮塔，如果沒(méi)有指揮塔的存在，每一架飛機(jī)要和方圓 100 公里內(nèi)的所有飛機(jī)通信，才能確定航線以及飛行狀況，后果是不可想象的?，F(xiàn)實(shí)中的情況是，每架飛機(jī)都只需要和指揮塔通信。指揮塔作為調(diào)停者，知道每一架飛機(jī)的飛行狀況，所以它可以安排所有飛機(jī)的起降時(shí)間，及時(shí)做出航線調(diào)整。

下面我們來(lái)看中介者模式在下面這個(gè)案例中的應(yīng)用。

中介者模式的例子

泡泡堂游戲

大家可能都還記得泡泡堂游戲，現(xiàn)在我們來(lái)一起回顧這個(gè)游戲，假設(shè)在游戲之初只支持兩個(gè)玩家同時(shí)進(jìn)行對(duì)戰(zhàn)。

先定義一個(gè)玩家構(gòu)造函數(shù)，它有 3 個(gè)簡(jiǎn)單的原型方法：Play.prototype.win、Play.prototype.lose 以及表示玩家死亡的 Play.prototype.die。

因?yàn)橥婕业臄?shù)目是 2，所以當(dāng)其中一個(gè)玩家死亡的時(shí)候游戲便結(jié)束, 同時(shí)通知它的對(duì)手勝利。 這段代碼看起來(lái)很簡(jiǎn)單：

function Player(name) {
	this.name = name
	this.enemy = null; // 敵人
};
Player.prototype.win = function () {
	console.log(this.name + ' won ');
};
Player.prototype.lose = function () {
	console.log(this.name + ' lost');
};
Player.prototype.die = function () {
	this.lose();
	this.enemy.win();
};

接下來(lái)創(chuàng)建 2 個(gè)玩家對(duì)象：

const player1 = new Player('玩家一');
const player2 = new Player('玩家二');

給玩家相互設(shè)置敵人：

player1.enemy = player2; 
player2.enemy = player1;

當(dāng)玩家 player1 被泡泡炸死的時(shí)候，只需要調(diào)用這一句代碼便完成了一局游戲：

player1.die();// 輸出：玩家一 lost、玩家二 won 

然而真正的泡泡堂游戲至多可以有 8 個(gè)玩家，并分成紅藍(lán)兩隊(duì)進(jìn)行游戲。

為游戲增加隊(duì)伍

現(xiàn)在我們改進(jìn)一下游戲。因?yàn)橥婕覕?shù)量變多，用下面的方式來(lái)設(shè)置隊(duì)友和敵人無(wú)疑很低效：

player1.partners = [player1, player2, player3, player4];
player1.enemies = [player5, player6, player7, player8];
Player5.partners = [player5, player6, player7, player8];
Player5.enemies = [player1, player2, player3, player4];

所以我們定義一個(gè)數(shù)組 players 來(lái)保存所有的玩家，在創(chuàng)建玩家之后，循環(huán) players 來(lái)給每個(gè)玩家設(shè)置隊(duì)友和敵人:

const players = []; 

再改寫構(gòu)造函數(shù) Player，使每個(gè)玩家對(duì)象都增加一些屬性，分別是隊(duì)友列表、敵人列表 、 玩家當(dāng)前狀態(tài)、角色名字以及玩家所在的隊(duì)伍顏色：

function Player(name, teamColor) {
	this.partners = []; // 隊(duì)友列表
	this.enemies = []; // 敵人列表
	this.state = 'live'; // 玩家狀態(tài)
	this.name = name; // 角色名字
	this.teamColor = teamColor; // 隊(duì)伍顏色
};

玩家勝利和失敗之后的展現(xiàn)依然很簡(jiǎn)單，只是在每個(gè)玩家的屏幕上簡(jiǎn)單地彈出提示：

Player.prototype.win = function () { // 玩家團(tuán)隊(duì)勝利
	console.log('winner: ' + this.name);
};
Player.prototype.lose = function () { // 玩家團(tuán)隊(duì)失敗
	console.log('loser: ' + this.name);
};

玩家死亡的方法要變得稍微復(fù)雜一點(diǎn)，我們需要在每個(gè)玩家死亡的時(shí)候，都遍歷其他隊(duì)友的生存狀況，如果隊(duì)友全部死亡，則這局游戲失敗，同時(shí)敵人隊(duì)伍的所有玩家都取得勝利，代碼如下：

Player.prototype.die = function () { // 玩家死亡
	let all_dead = true;
	this.state = 'dead'; // 設(shè)置玩家狀態(tài)為死亡
	for (let i = 0; i < this.partners.length; i++) { // 遍歷隊(duì)友列表
		if (this.partners[i].state !== 'dead') { // 如果還有一個(gè)隊(duì)友沒(méi)有死亡，則游戲還未失敗
			all_dead = false;
			break;
		}
	}
	if (all_dead === true) { // 如果隊(duì)友全部死亡
		this.lose(); // 通知自己游戲失敗
		for (let i = 0; i < this.partners.length; i++) { // 通知所有隊(duì)友玩家游戲失敗
			this.partners[i].lose();
		}
		for (let i = 0; i < this.enemies.length; i++) { // 通知所有敵人游戲勝利
			this.enemies[i].win();
		}
	}
};

最后定義一個(gè)工廠來(lái)創(chuàng)建玩家：

const playerFactory = function (name, teamColor) {
	const newPlayer = new Player(name, teamColor); // 創(chuàng)建新玩家
	for (let i = 0; i < players.length; i++) { // 通知所有的玩家，有新角色加入
		if (players[i].teamColor === newPlayer.teamColor) { // 如果是同一隊(duì)的玩家
			players[i].partners.push(newPlayer); // 相互添加到隊(duì)友列表
			newPlayer.partners.push(players[i]);
		} else {
			players[i].enemies.push(newPlayer); // 相互添加到敵人列表
			newPlayer.enemies.push(players[i]);
		}
	}
	players.push(newPlayer);
	return newPlayer;
};

現(xiàn)在來(lái)感受一下, 用這段代碼創(chuàng)建 8 個(gè)玩家：

//紅隊(duì)：
var player1 = playerFactory('皮蛋', 'red'),
	player2 = playerFactory('小乖', 'red'),
	player3 = playerFactory('寶寶', 'red'),
	player4 = playerFactory('小強(qiáng)', 'red');
//藍(lán)隊(duì)：
var player5 = playerFactory('黑妞', 'blue'),
	player6 = playerFactory('蔥頭', 'blue'),
	player7 = playerFactory('胖墩', 'blue'),
	player8 = playerFactory('海盜', 'blue');

讓紅隊(duì)玩家全部死亡：

player1.die();
player2.die();
player4.die();
player3.die();

結(jié)果如下：

loser: 寶寶
loser: 皮蛋
loser: 小乖
loser: 小強(qiáng)
winner: 黑妞
winner: 蔥頭
winner: 胖墩
winner: 海盜

玩家增多帶來(lái)的困擾

現(xiàn)在我們已經(jīng)可以隨意地為游戲增加玩家或者隊(duì)伍，但問(wèn)題是，每個(gè)玩家和其他玩家都是緊緊耦合在一起的。在此段代碼中，每個(gè)玩家對(duì)象都有兩個(gè)屬性，this.partners 和 this.enemies，用來(lái)保存其他玩家對(duì)象的引用。當(dāng)每個(gè)對(duì)象的狀態(tài)發(fā)生改變，比如角色移動(dòng)、吃到道具或者死亡時(shí)，都必須要顯式地遍歷通知其他對(duì)象。

在這個(gè)例子中只創(chuàng)建了 8 個(gè)玩家，或許還沒(méi)有對(duì)你產(chǎn)生足夠多的困擾，而如果在一個(gè)大型網(wǎng)絡(luò)游戲中，畫面里有成百上千個(gè)玩家，幾十支隊(duì)伍在互相廝殺。如果有一個(gè)玩家掉線，必須從所有其他玩家的隊(duì)友列表和敵人列表中都移除這個(gè)玩家。游戲也許還有解除隊(duì)伍和添加到別的隊(duì)伍的功能，紅色玩家可以突然變成藍(lán)色玩家，這就不再僅僅是循環(huán)能夠解決的問(wèn)題了。面對(duì)這樣的需求，我們上面的代碼可以迅速進(jìn)入投降模式。

用中介者模式改造泡泡堂游戲

現(xiàn)在我們開(kāi)始用中介者模式來(lái)改造上面的泡泡堂游戲， 改造后的玩家對(duì)象和中介者的關(guān)系如下圖所示。

首先仍然是定義 Player 構(gòu)造函數(shù)和 player 對(duì)象的原型方法，在 player 對(duì)象的這些原型方法 中，不再負(fù)責(zé)具體的執(zhí)行邏輯，而是把操作轉(zhuǎn)交給中介者對(duì)象，我們把中介者對(duì)象命名為 playerDirector：

function Player(name, teamColor) {
	this.name = name; // 角色名字
	this.teamColor = teamColor; // 隊(duì)伍顏色 
	this.state = 'alive'; // 玩家生存狀態(tài)
};
Player.prototype.win = function () {
	console.log(this.name + ' won ');
};
Player.prototype.lose = function () {
	console.log(this.name + ' lost');
};
/*******************玩家死亡*****************/
Player.prototype.die = function () {
	this.state = 'dead';
	playerDirector.reciveMessage('playerDead', this); // 給中介者發(fā)送消息，玩家死亡
};
/*******************移除玩家*****************/
Player.prototype.remove = function () {
	playerDirector.reciveMessage('removePlayer', this); // 給中介者發(fā)送消息，移除一個(gè)玩家
};
/*******************玩家換隊(duì)*****************/
Player.prototype.changeTeam = function (color) {
	playerDirector.reciveMessage('changeTeam', this, color); // 給中介者發(fā)送消息，玩家換隊(duì)
};

再繼續(xù)改寫之前創(chuàng)建玩家對(duì)象的工廠函數(shù)，可以看到，因?yàn)楣S函數(shù)里不再需要給創(chuàng)建的玩家對(duì)象設(shè)置隊(duì)友和敵人，這個(gè)工廠函數(shù)幾乎失去了工廠的意義：

const playerFactory = function (name, teamColor) {
	const newPlayer = new Player(name, teamColor); // 創(chuàng)造一個(gè)新的玩家對(duì)象
	playerDirector.reciveMessage('addPlayer', newPlayer); // 給中介者發(fā)送消息，新增玩家
	return newPlayer;
};

最后，我們需要實(shí)現(xiàn)這個(gè)中介者 playerDirector 對(duì)象，一般有以下兩種方式。

• 利用發(fā)布—訂閱模式。將 playerDirector 實(shí)現(xiàn)為訂閱者，各 player 作為發(fā)布者，一旦 player 的狀態(tài)發(fā)生改變，便推送消息給 playerDirector，playerDirector 處理消息后將反饋發(fā)送 給其他 player。
• 在 playerDirector 中開(kāi)放一些接收消息的接口，各 player 可以直接調(diào)用該接口來(lái)給 playerDirector 發(fā)送消息，player 只需傳遞一個(gè)參數(shù)給 playerDirector，這個(gè)參數(shù)的目的是使 playerDirector 可以識(shí)別發(fā)送者。同樣，playerDirector 接收到消息之后會(huì)將處理結(jié)果反饋給其他 player。

這兩種方式的實(shí)現(xiàn)沒(méi)什么本質(zhì)上的區(qū)別。在這里我們使用第二種方式，playerDirector 開(kāi)放一個(gè)對(duì)外暴露的接口 reciveMessage，負(fù)責(zé)接收 player 對(duì)象發(fā)送的消息，而 player 對(duì)象發(fā)送消息的時(shí)候，總是把自身 this 作為參數(shù)發(fā)送給 playerDirector，以便 playerDirector 識(shí)別消息來(lái)自于哪個(gè)玩家對(duì)象，代碼如下：

const playerDirector = (function () {
	const players = {}, // 保存所有玩家
		operations = {}; // 中介者可以執(zhí)行的操作
	/**
	 * 新增一個(gè)玩家
	 * @param {Player} player 玩家
	 */
	operations.addPlayer = function (player) {
		const teamColor = player.teamColor; // 玩家的隊(duì)伍顏色
		// 如果該顏色的玩家還沒(méi)有成立隊(duì)伍，則新成立一個(gè)隊(duì)伍
		players[teamColor] = players[teamColor] || [];
		players[teamColor].push(player); // 添加玩家進(jìn)隊(duì)伍
	};
	/**
	 * 移除一個(gè)玩家
	 * @param {Player} player 玩家
	 */
	operations.removePlayer = function (player) {
		const teamColor = player.teamColor, // 玩家的隊(duì)伍顏色
			teamPlayers = players[teamColor] || []; // 該隊(duì)伍所有成員
		for (let i = teamPlayers.length - 1; i >= 0; i--) { // 遍歷刪除
			if (teamPlayers[i] === player) {
				teamPlayers.splice(i, 1);
			}
		}
	};
	/**
	 * 玩家換隊(duì)
	 * @param {Player} player 玩家
	 * @param {string} newTeamColor 隊(duì)伍顏色
	 */
	operations.changeTeam = function (player, newTeamColor) { // 玩家換隊(duì)
		operations.removePlayer(player); // 從原隊(duì)伍中刪除
		player.teamColor = newTeamColor; // 改變隊(duì)伍顏色
		operations.addPlayer(player); // 增加到新隊(duì)伍中
	};
	/**
	 * 玩家死亡
	 * @param {Player} player 玩家
	 */
	operations.playerDead = function (player) {
		const teamColor = player.teamColor,
			teamPlayers = players[teamColor]; // 玩家所在隊(duì)伍
		let all_dead = true;
		for (let i = 0; i < teamPlayers.length; i++) {
			if (teamPlayers[i].state !== 'dead') {
				all_dead = false;
				break;
			}
		}
		if (all_dead) { // 全部死亡
			for (let i = 0; i < teamPlayers.length; i++) {
				teamPlayers[i].lose(); // 本隊(duì)所有玩家 lose 
			}
			for (const color in players) {
				if (color !== teamColor) {
					const teamPlayers = players[color]; // 其他隊(duì)伍的玩家
					for (let i = 0; i < teamPlayers.length; i++) {
						teamPlayers[i].win(); // 其他隊(duì)伍所有玩家 win 
					}
				}
			}
		}
	};
	const reciveMessage = function () {
		// arguments 的第一個(gè)參數(shù)為消息名稱
		const message = Array.prototype.shift.call(arguments); 
		operations[message].apply(this, arguments);
	};
	return {
		reciveMessage
	}
})();

可以看到，除了中介者本身，沒(méi)有一個(gè)玩家知道其他任何玩家的存在，玩家與玩家之間的耦合關(guān)系已經(jīng)完全解除，某個(gè)玩家的任何操作都不需要通知其他玩家，而只需要給中介者發(fā)送一個(gè)消息，中介者處理完消息之后會(huì)把處理結(jié)果反饋給其他的玩家對(duì)象。我們還可以繼續(xù)給中介者擴(kuò)展更多功能，以適應(yīng)游戲需求的不斷變化。

我們來(lái)看下測(cè)試結(jié)果：

// 紅隊(duì)：
var player1 = playerFactory('皮蛋', 'red'),
	player2 = playerFactory('小乖', 'red'),
	player3 = playerFactory('寶寶', 'red'),
	player4 = playerFactory('小強(qiáng)', 'red');
// 藍(lán)隊(duì)：
var player5 = playerFactory('黑妞', 'blue'),
	player6 = playerFactory('蔥頭', 'blue'),
	player7 = playerFactory('胖墩', 'blue'),
	player8 = playerFactory('海盜', 'blue');
player1.die();
player2.die();
player3.die();
player4.die();

運(yùn)行結(jié)果如下。

皮蛋 lost
小乖 lost
寶寶 lost
小強(qiáng) lost
黑妞 won
蔥頭 won
胖墩 won
海盜 won

假設(shè)皮蛋和小乖掉線

player1.remove(); 
player2.remove(); 
player3.die(); 
player4.die(); 

則結(jié)果如下。

寶寶 lost
小強(qiáng) lost
黑妞 won
蔥頭 won
胖墩 won
海盜 won

假設(shè)皮蛋從紅隊(duì)叛變到藍(lán)隊(duì)

player1.changeTeam( 'blue' ); 
player2.die(); 
player3.die(); 
player4.die(); 

則結(jié)果如下。

小乖 lost
寶寶 lost
小強(qiáng) lost
黑妞 won
蔥頭 won
胖墩 won
海盜 won
皮蛋 won

小結(jié)

中介者模式是迎合迪米特法則的一種實(shí)現(xiàn)。迪米特法則也叫最少知識(shí)原則，是指一個(gè)對(duì)象應(yīng)該盡可能少地了解另外的對(duì)象（類似不和陌生人說(shuō)話）。如果對(duì)象之間的耦合性太高，一個(gè)對(duì)象發(fā)生改變之后，難免會(huì)影響到其他的對(duì)象，跟“城門失火，殃及池魚(yú)”的道理是一樣的。而在中介者模式里，對(duì)象之間幾乎不知道彼此的存在，它們只能通過(guò)中介者對(duì)象來(lái)互相影響對(duì)方。

因此，中介者模式使各個(gè)對(duì)象之間得以解耦，以中介者和對(duì)象之間的一對(duì)多關(guān)系取代了對(duì)象之間的網(wǎng)狀多對(duì)多關(guān)系。各個(gè)對(duì)象只需關(guān)注自身功能的實(shí)現(xiàn)，對(duì)象之間的交互關(guān)系交給了中介者 對(duì)象來(lái)實(shí)現(xiàn)和維護(hù)。

不過(guò)，中介者模式也存在一些缺點(diǎn)。其中，最大的缺點(diǎn)是系統(tǒng)中會(huì)新增一個(gè)中介者對(duì)象，因?yàn)閷?duì)象之間交互的復(fù)雜性，轉(zhuǎn)移成了中介者對(duì)象的復(fù)雜性，使得中介者對(duì)象經(jīng)常是巨大的。中介者對(duì)象自身往往就是一個(gè)難以維護(hù)的對(duì)象。

中介者模式可以非常方便地對(duì)模塊或者對(duì)象進(jìn)行解耦，但對(duì)象之間并非一定需要解耦。在實(shí)際項(xiàng)目中，模塊或?qū)ο笾g有一些依賴關(guān)系是很正常的。畢竟我們寫程序是為了快速完成項(xiàng)目交付生產(chǎn)，而不是堆砌模式和過(guò)度設(shè)計(jì)。關(guān)鍵就在于如何去衡量對(duì)象之間的耦合程度。一般來(lái)說(shuō)， 如果對(duì)象之間的復(fù)雜耦合確實(shí)導(dǎo)致調(diào)用和維護(hù)出現(xiàn)了困難，而且這些耦合度隨項(xiàng)目的變化呈指數(shù)增長(zhǎng)曲線，那我們就可以考慮用中介者模式來(lái)重構(gòu)代碼。

到此這篇關(guān)于JavaScript設(shè)計(jì)模式之中介者模式詳解的文章就介紹到這了,更多相關(guān)JS中介者模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論