適配器模式

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

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

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

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

下面這個實例可以幫助我們深刻了解適配器模式。

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

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

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

baiduMap 這個對象來源于第三方，正常情況下我們都不應(yīng)該去改動它。此時我們可以通過增 加 baiduMapAdapter 來解決問題：

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

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

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

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

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

除了大動干戈地改寫渲染頁面的前端代碼之外，另外一種更輕便的解決方式就是新增一個數(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('開始渲染廣東省地圖');
	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));

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

小結(jié)

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

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

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

最新評論