介面卡模式（Adapter）

介面卡模式主要用來解決兩個已有介面之間不匹配的問題，它不考慮這些介面是怎樣實現的，也不考慮它們將來可能會如何演化。介面卡模式不需要改變已有的介面，就能夠使它們協同作用。

介面卡的別名是包裝器（wrapper），這是一個相對簡單的模式。在程式開發中有許多這樣的場景：當我們試圖呼叫模組或者物件的某個介面時，卻發現這個介面的格式並不符合目前的需求。這時候有兩種解決辦法，第一種是修改原來的介面實現，但如果原來的模組很複雜，或者我們拿到的模組是一段別人編寫的經過壓縮的程式碼，修改原介面就顯得不太現實了。第二種辦法是建立一個介面卡，將原介面轉換為客戶希望的另一個介面，客戶只需要和介面卡打交道。

現實中也有很多介面卡的例子：電源插座，usb介面卡等等；例如iPhone7以後的耳機介面從3.5mm圓孔介面更改成為了蘋果專屬的 lightning介面。許多人以前的圓孔耳機就需要下面的一個介面卡，才能夠在自個兒新買的iPhone上面聽歌。

2. 介面卡模式使用場景

2.1 介面適配

當我們向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

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); // 輸出：開始渲染百度地圖

2.2 引數的適配

有的情況下一個方法可能需要傳入多個引數，例如在做一些監控上報的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.....
  }
}

2.3 資料的適配

資料的適配在前端中是最為常見的場景，這時介面卡在解決前後端的資料依賴上有著重要的意義。通常伺服器端傳遞的資料和我們前端需要使用的資料格式是不一致的，特別是在在使用一些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);
}

3 總結

介面卡模式是一對相對簡單的模式。但介面卡模式在JS中的使用場景很多，在引數的適配上，有許多庫和框架都使用介面卡模式；資料的適配在解決前後端資料依賴上十分重要。我們要認識到的是介面卡模式本質上是一個”亡羊補牢”的模式，它解決的是現存的兩個介面之間不相容的問題，你不應該在軟體的初期開發階段就使用該模式；如果在設計之初我們就能夠統籌的規劃好介面的一致性，那麼介面卡就應該儘量減少使用。

在JavaScript中的介面卡更多應用於在物件之間，為了使物件可用，我們通常會將物件拆分並重新組裝，這樣就必須瞭解適配物件的內部結構，這也是和外觀模式的區別所在，當然是配資模式同樣解決了物件之間的耦合度，包裝的適配程式碼增加了一些資源消耗，但這是微乎其微的。