摘要：什么是適配器模式適配器模式將一個類的接口轉換成客戶希望的另外一個接口，使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。中的適配器模式在前端項目中，適配器模式的使用場景一般有以下三種情況庫的適配參數的適配和數據的適配。

適配器模式(Adapter)：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。

在生活中，我們有許多的適配器，例如iPhone7以后的耳機接口從3.5mm圓孔接口更改成為了蘋果專屬的 lightning接口。許多人以前的圓孔耳機就需要下面的一個適配器，才能夠在自個兒新買的iPhone上面聽歌。

在前端開發中，我們可能會遇見這樣的場景：當我們試圖調用某個模塊或者對象的接口時，卻發現這個接口的格式不符合我們的需求。這時有兩種解決辦法：第一種是修改原來的接口實現，但如果原來的代碼很復雜，例如是一個庫或框架，更改原代碼就顯得很不現實了。所以這時就需要使用今天所講的第二種辦法：創建一個適配器，將原接口轉換為客戶希望的另一個接口，客戶只需要使用適配器即可。

對于只有JavaScript這一門語言經驗的前端開發來說，可能對于接口的概念比較陌生。建議參考閱讀TypeScript-接口的文檔來更好的理解接口。

在前端項目中，適配器模式的使用場景一般有以下三種情況：庫的適配、參數的適配和數據的適配。下面我將以我在項目中的實際例子來說明。

項目上線前通常會要求前端開發者在頁面中會接入統計網頁數據用的SDK，這些SDK能夠采集用戶的信息和網頁行生成可視化的圖表和表格，來幫助網站運營人員和產品經理更好的根據用戶行為來提升網頁質量。我們來看一下適配器在接入采集數據的庫時的使用場景：

目前國內做得比較好的數據分析網站有百度統計、神策數據、友盟等。在一個你做的電商類網站 項目上線前，你的產品經理要求你接入了百度的代碼用于數據采集，并在幾十個涉及用戶操作的地方進行了埋點。百度統計提供的埋點接口格式如下：

 _hmt.push(["_trackEvent", category, action, opt_label,opt_value]);

按照產品經理的要求，你根據上面的格式將埋點代碼寫到了頁面的多個地方：

//index.html
_hmt.push(["_trackEvent", "web", "page_enter", "position", "index.html"]);

//product-detail.html
_hmt.push(["_trackEvent", "web", "page_enter", "position", "product-detail.html"]);

_hmt.push(["_trackEvent", "web", "product_detail_view", "product_id", productId]);

_hmt.push(["_trackEvent", "web", "add-product-chart", "product_id", productId]);

//...還有幾十個頁面

過了幾個月之后，該電商網站發展速度很快，運營人員感覺到百度統計提供的采集數據在已經無法滿足當前網站的規模。運營人員和產品經理商量后決定，數據采集平臺需要從百度統計切換到神策數據，神策數據提供的埋點接口格式如下：

sa.track(eventName, {
  attrName: value 
})

接口的規則不同，就意味著你需要將幾十個百度統計的_htm.push接口更改成為神策提供的sa.track接口。其實不用這么麻煩，寫一個適配器就可以完成所有埋點事件的遷移：

//app.js

let _hmt = {
  push: (arr) {
    
    const [eventName, attrName, value] = [...arr.splice(2)];
    
    let attrObj = {
      [attrName]: value
    };

    sa.track(eventName, attrObj);
  }
}

通過分析比較百度統計的接口和神策的接口，可以知道在神策中只需要傳入三個參數，eventName對應的是百度統計接口中的action, attrName對應的是百度統計接口中的opt_label， value對應的是百度統計接口中的opt_value; 刪除了百度統計的SDK后，SDK所提供的_htm這個全局變量也就不存在了，我們可以利用該變量名做適配器，在push方法獲取sa.track所需要的三個參數并調用sa.track即可。

有的情況下一個方法可能需要傳入多個參數，例如在SDK這個類中有一個phoneStatus，需要傳入五個參數用于接收手機的相關信息：

class SDK {
  phoneStatus(brand, os, carrier, language, network) {

    //dosomething.....
  }
}

通常在傳入的參數大于3的時候，我們就可以考慮將參數合并為一個對象的形式，就像我們$.ajax的做法一樣。下面我們可以將phoneStatus的參數接口定義如下（String代表參數類型，?: 代表可選項）

{
  brand: String
  os: String
  carrier:? String
  language:? String
  network:? String
}

可以看出，carrier、language，network這三個屬性不是必須傳入的，它們在方法內部可能被設置一些默認值。所以這個時候我們就可以在方法內部采用適配器來適配這個參數對象。

class SDK {
  phoneStatus(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中的使用場景很多，在參數的適配上，有許多庫和框架都使用適配器模式；數據的適配在解決前后端數據依賴上十分重要。但是適配器模式本質上是一個亡羊補牢的模式，它解決的是現存的兩個接口之間不兼容的問題，你不應該在軟件的初期開發階段就使用該模式；如果在設計之初我們就能夠統籌的規劃好接口的一致性，那么適配器就應該盡量減少使用。

[1] 張榮銘 JavaScript設計模式 [M].人民郵電出版社

[2] 程杰 大話設計模式 [M].清華大學出版社

[3] 曾探 JavaScript設計模式與開發實踐 [M].r人民郵電出版社