適配器模式

適配器模式的作用是解決兩個(gè)軟件實(shí)體間的接口不兼容的問(wèn)題。使用適配器模式之后，原本由于接口不兼容而不能工作的兩個(gè)軟件實(shí)體可以一起工作。

適配器的別名是包裝器（wrapper），這是一個(gè)相對(duì)簡(jiǎn)單的模式。在程序開(kāi)發(fā)中有許多這樣的場(chǎng)景：當(dāng)我們?cè)噲D調(diào)用模塊或者對(duì)象的某個(gè)接口時(shí)，卻發(fā)現(xiàn)這個(gè)接口的格式并不符合目前的需求。這時(shí)候有兩種解決辦法，第一種是修改原來(lái)的接口實(shí)現(xiàn)，但如果原來(lái)的模塊很復(fù)雜，或者我們拿到的模塊是一段別人編寫(xiě)的經(jīng)過(guò)壓縮的代碼，修改原接口就顯得不太現(xiàn)實(shí)了。第二種辦法是創(chuàng)建一個(gè)適配器，將原接口轉(zhuǎn)換為客戶希望的另一個(gè)接口，客戶只需要和適配器打交道。

適配器模式的應(yīng)用

如果現(xiàn)有的接口已經(jīng)能夠正常工作，那我們就永遠(yuǎn)不會(huì)用上適配器模式。適配器模式是一種“亡羊補(bǔ)牢”的模式，沒(méi)有人會(huì)在程序的設(shè)計(jì)之初就使用它。因?yàn)闆](méi)有人可以完全預(yù)料到未來(lái)的事情，也許現(xiàn)在好好工作的接口，未來(lái)的某天卻不再適用于新系統(tǒng)，那么我們可以用適配器模式把舊接口包裝成一個(gè)新的接口，使它繼續(xù)保持生命力。比如在 JSON 格式流行之前，很多 api返回的都是 XML 格式的數(shù)據(jù)，如果今天仍然想繼續(xù)使用這些接口，顯然我們可以創(chuàng)造一個(gè) XML-JSON 的適配器。

下面這個(gè)實(shí)例可以幫助我們深刻了解適配器模式。

當(dāng)我們向 googleMap 和 baiduMap 都發(fā)出“顯示”請(qǐng)求時(shí)，googleMap 和 baiduMap 分別以各自的方式在頁(yè)面中展現(xiàn)了地圖：

const googleMap = {
	show: function () {
		console.log('開(kāi)始渲染谷歌地圖');
	}
};
const baiduMap = {
	show: function () {
		console.log('開(kāi)始渲染百度地圖');
	}
};
const renderMap = function (map) {
	if (map.show instanceof Function) {
		map.show();
	}
};
renderMap(googleMap); // 輸出：開(kāi)始渲染谷歌地圖 
renderMap(baiduMap); // 輸出：開(kāi)始渲染百度地圖 

這段程序得以順利運(yùn)行的關(guān)鍵是 googleMap 和 baiduMap 提供了一致的 show 方法，但第三方的接口方法并不在我們自己的控制范圍之內(nèi)，假如 baiduMap 提供的顯示地圖的方法不叫 show 而叫 display 呢？

baiduMap 這個(gè)對(duì)象來(lái)源于第三方，正常情況下我們都不應(yīng)該去改動(dòng)它。此時(shí)我們可以通過(guò)增 加 baiduMapAdapter 來(lái)解決問(wèn)題：

const googleMap = {
	show: function () {
		console.log('開(kāi)始渲染谷歌地圖');
	}
};
const baiduMap = {
	display: function () {
		console.log('開(kāi)始渲染百度地圖');
	}
};
const baiduMapAdapter = {
	show: function () {
		return baiduMap.display();
	}
};
renderMap(googleMap); // 輸出：開(kāi)始渲染谷歌地圖
renderMap(baiduMapAdapter); // 輸出：開(kāi)始渲染百度地圖

再來(lái)看看另外一個(gè)例子。假設(shè)我們正在編寫(xiě)一個(gè)渲染廣東省地圖的頁(yè)面。目前從第三方資源里獲得了廣東省的所有城市以及它們所對(duì)應(yīng)的 ID，并且成功地渲染到頁(yè)面中：

const getGuangdongCity = function () {
	const guangdongCity = [{
		name: 'shenzhen',
		id: 11,
	}, {
		name: 'guangzhou',
		id: 12,
	}];
	return guangdongCity;
};
const render = function (fn) {
	console.log('開(kāi)始渲染廣東省地圖');
	document.write(JSON.stringify(fn()));
};
render(getGuangdongCity);

利用這些數(shù)據(jù)，我們編寫(xiě)完成了整個(gè)頁(yè)面，并且在線上穩(wěn)定地運(yùn)行了一段時(shí)間。但后來(lái)發(fā)現(xiàn)這些數(shù)據(jù)不太可靠，里面還缺少很多城市。于是我們又在網(wǎng)上找到了另外一些數(shù)據(jù)資源，這次的數(shù)據(jù)更加全面，但遺憾的是，數(shù)據(jù)結(jié)構(gòu)和正運(yùn)行在項(xiàng)目中的并不一致。新的數(shù)據(jù)結(jié)構(gòu)如下：

const guangdongCity = {
	shenzhen: 11,
	guangzhou: 12,
	zhuhai: 13
};

除了大動(dòng)干戈地改寫(xiě)渲染頁(yè)面的前端代碼之外，另外一種更輕便的解決方式就是新增一個(gè)數(shù)據(jù)格式轉(zhuǎn)換的適配器：

const getGuangdongCity = function () {
	const guangdongCity = [{
		name: 'shenzhen',
		id: 11,
	}, {
		name: 'guangzhou',
		id: 12,
	}];
	return guangdongCity;
};
const render = function (fn) {
	console.log('開(kāi)始渲染廣東省地圖');
	document.write(JSON.stringify(fn()));
};
const addressAdapter = function (oldAddressfn) {
	const address = {},
		oldAddress = oldAddressfn();
	for (let i = 0; i < oldAddress.length; i++) {
		address[oldAddress[i].name] = c.id;
	}
	return function () {
		return address;
	}
};
render(addressAdapter(getGuangdongCity));

那么接下來(lái)需要做的，就是把代碼中調(diào)用 getGuangdongCity 的地方，用經(jīng)過(guò) addressAdapter 適配器轉(zhuǎn)換之后的新函數(shù)來(lái)代替。

小結(jié)

適配器模式是一對(duì)相對(duì)簡(jiǎn)單的模式。有一些模式跟適配器模式的結(jié)構(gòu)非常相似，比如裝飾者模式、代理模式和外觀模式。這幾種模式都屬于“包裝模式”，都是由一個(gè)對(duì)象來(lái)包裝另一個(gè)對(duì)象。區(qū)別它們的關(guān)鍵仍然是模式的意圖。

• 適配器模式主要用來(lái)解決兩個(gè)已有接口之間不匹配的問(wèn)題，它不考慮這些接口是怎樣實(shí)現(xiàn)的，也不考慮它們將來(lái)可能會(huì)如何演化。適配器模式不需要改變已有的接口，就能夠使它們協(xié)同作用。
• 裝飾者模式和代理模式也不會(huì)改變?cè)袑?duì)象的接口，但裝飾者模式的作用是為了給對(duì)象增加功能。裝飾者模式常常形成一條長(zhǎng)的裝飾鏈，而適配器模式通常只包裝一次。代理 模式是為了控制對(duì)對(duì)象的訪問(wèn)，通常也只包裝一次。
• 外觀模式的作用倒是和適配器比較相似，有人把外觀模式看成一組對(duì)象的適配器，但外觀模式最顯著的特點(diǎn)是定義了一個(gè)新的接口。

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

最新評(píng)論