適配器模式主要用來解決兩個已有介面之間不匹配的問題，它不考慮這些介面是怎樣實現的，也不考慮它們將來可能會如何演化。適配器模式不需要改變現有的接口，就能夠使它們協同作用。
適配器的別名是包裝器（wrapper），這是一個相對簡單的模式。在程式開發中有許多這樣的場景：當我們試著呼叫模組或物件的某個介面時，卻發現這個介面的格式並不符合目前的需求。這時候有兩種解決辦法，第一種是修改原來的介面實現，但如果原來的模組很複雜，或是我們拿到的模組是一段別人寫的經過壓縮的程式碼，修改原介面就顯得不太現實了。第二種辦法是建立一個適配器，將原介面轉換為客戶希望的另一個接口，客戶只需要和適配器打交道。
現實中也有很多適配器的例子：電源插座，usb適配器等等；例如iPhone7以後的耳機接口從3.5mm圓孔接口更改成為了蘋果專屬的 lightning接口。許多人以前的圓孔耳機就需要下面的一個轉接器，才能夠在自個兒新買的iPhone上面聽歌。
當我們向googleMap 和baiduMap都發出「顯示」請求時，googleMap和baiduMap` 分別以各自的方式在頁面中展現了地圖
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); // 输出：开始渲染百度地图這段程式得以順利運行的關鍵是googleMap 和baiduMap 提供了一致的show 方法，但第三方的介面方法並不在我們自己的控制範圍之內，假如baiduMap 提供的顯示地圖的方法不叫show 而叫做display 呢？
baiduMap 這個物件來自第三方，正常情況下我們都不應該去改動它,而且有時候我們也改不了它。此時我們可以透過增加baiduMapAdapter 來解決問題：
const googleMap = {
show: function () {
console.log('开始渲染谷歌地图');
}
};const baiduMap = {
display: function () {
console.log('开始渲染百度地图');
}
};const baiduMapAdapter = {
show: function(){
return baiduMap.display();
}
};
renderMap(googleMap); // 输出：开始渲染谷歌地图renderMap(baiduMapAdapter); // 输出：开始渲染百度地图有的情況下一個方法可能需要傳入多個參數，例如在做一些監控上報的SDK時，可能收集的資料比較多，這個類別中有一個systemInfo#，需要傳入五個參數來接收手機的相關資訊：
class SDK {
systemInf(brand, os, carrier, language, network) { //dosomething.....
}
}通常在傳入的參數大於3的時候，我們就可以考慮將參數合併為一個物件的形式，就像我們$.ajax的做法一樣。下面我們可以將systemInfo的參數介面定義如下（String代表參數類型，?: 代表可選項）
{
brand: String
os: String
carrier:? String
language:? String
network:? String}可以看出，carrier、language，network這三個屬性不是必須傳入的，它們在方法內部可能被設定一些預設值。所以這個時候我們就可以在方法內部採用適配器來適應這個參數物件。這種方式在我們的插件或npm套件中是常見的；
class SDK {
systemInf(config) { let defaultConfig = {
brand: null, //手机品牌
os: null, //系统类型： Andoird或 iOS
carrier: 'china-mobile', //运营商，默认中国移动
language: 'zh', //语言类型，默认中文
network: 'wifi', //网络类型，默认wifi
} //参数适配
for( let i in config) {
defaultConfig[i] = config[i] || defaultConfig[i];
} //dosomething.....
}
}資料的適配在前端中是最為常見的場景，這時適配器在解決前後端的數據依賴上有著重要的意義。通常伺服器端傳遞的資料和我們前端需要使用的資料格式是不一致的，特別是在使用一些UI框架時，框架所規定的資料有著固定的格式。所以，這個時候我們就需要對後端的資料格式進行適配。
例如網頁中有一個使用Echarts折線圖對網站每週的uv，通常後端回傳的資料格式如下所示：
[
{ "day": "周一", "uv": 6300
},
{ "day": "周二", "uv": 7100
}, { "day": "周三", "uv": 4300
}, { "day": "周四", "uv": 3300
}, { "day": "周五", "uv": 8300
}, { "day": "周六", "uv": 9300
}, { "day": "周日", "uv": 11300
}
]但是Echarts需要的x軸的資料格式和座標點的資料是長下面這樣的:
["周二", "周二", "周三"， "周四"， "周五"， "周六"， "周日"] //x轴的数据[6300. 7100, 4300, 3300, 8300, 9300, 11300] //坐标点的数据
所以這是我們就可以使用一個適配器，將後端的回傳資料做為適配：
//x轴适配器function echartXAxisAdapter(res) {
return res.map(item => item.day);
}//坐标点适配器function echartDataAdapter(res) {
return res.map(item => item.uv);
}#適配器模式是一對相對簡單的模式。但適配器模式在JS中的使用場景很多，在參數的適配器上，有許多函式庫和框架都使用適配器模式；資料的適配在解決前後端資料依賴上十分重要。我們要認識到的是適配器模式本質上是一個」亡羊補牢」的模式，它解決的是現存的兩個介面之間不相容的問題，你不應該在軟體的初期開發階段就使用該模式；如果在設計之初我們就能夠統籌的規劃好介面的一致性，那麼適配器就應該盡量減少使用。
在JavaScript中的適配器更多應用於在物件之間，為了使物件可用，我們通常會將物件拆分並重新組裝，這樣就必須了解適配器物件的內部結構，這也是和外觀模式的區別所在，當然是配資模式同樣解決了物件之間的耦合度，包裝的適配程式碼增加了一些資源消耗，但這是微不足道的。
相關文章：
##以上是JavaScript設計模式之簡單介紹適配器模式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
