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

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

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

在前端開(kāi)發(fā)中，我們可能會(huì)遇見(jiàn)這樣的場(chǎng)景：當(dāng)我們?cè)噲D調(diào)用某個(gè)模塊或者對(duì)象的接口時(shí)，卻發(fā)現(xiàn)這個(gè)接口的格式不符合我們的需求。這時(shí)有兩種解決辦法：第一種是修改原來(lái)的接口實(shí)現(xiàn)，但如果原來(lái)的代碼很復(fù)雜，例如是一個(gè)庫(kù)或框架，更改原代碼就顯得很不現(xiàn)實(shí)了。所以這時(shí)就需要使用今天所講的第二種辦法：創(chuàng)建一個(gè)適配器，將原接口轉(zhuǎn)換為客戶希望的另一個(gè)接口，客戶只需要使用適配器即可。

對(duì)于只有JavaScript這一門語(yǔ)言經(jīng)驗(yàn)的前端開(kāi)發(fā)來(lái)說(shuō)，可能對(duì)于接口的概念比較陌生。建議參考閱讀TypeScript-接口的文檔來(lái)更好的理解接口。

在前端項(xiàng)目中，適配器模式的使用場(chǎng)景一般有以下三種情況：庫(kù)的適配、參數(shù)的適配和數(shù)據(jù)的適配。下面我將以我在項(xiàng)目中的實(shí)際例子來(lái)說(shuō)明。

項(xiàng)目上線前通常會(huì)要求前端開(kāi)發(fā)者在頁(yè)面中會(huì)接入統(tǒng)計(jì)網(wǎng)頁(yè)數(shù)據(jù)用的SDK，這些SDK能夠采集用戶的信息和網(wǎng)頁(yè)行生成可視化的圖表和表格，來(lái)幫助網(wǎng)站運(yùn)營(yíng)人員和產(chǎn)品經(jīng)理更好的根據(jù)用戶行為來(lái)提升網(wǎng)頁(yè)質(zhì)量。我們來(lái)看一下適配器在接入采集數(shù)據(jù)的庫(kù)時(shí)的使用場(chǎng)景：

目前國(guó)內(nèi)做得比較好的數(shù)據(jù)分析網(wǎng)站有百度統(tǒng)計(jì)、神策數(shù)據(jù)、友盟等。在一個(gè)你做的電商類網(wǎng)站 項(xiàng)目上線前，你的產(chǎn)品經(jīng)理要求你接入了百度的代碼用于數(shù)據(jù)采集，并在幾十個(gè)涉及用戶操作的地方進(jìn)行了埋點(diǎn)。百度統(tǒng)計(jì)提供的埋點(diǎn)接口格式如下：

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

按照產(chǎn)品經(jīng)理的要求，你根據(jù)上面的格式將埋點(diǎn)代碼寫到了頁(yè)面的多個(gè)地方：

//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]);

//...還有幾十個(gè)頁(yè)面

過(guò)了幾個(gè)月之后，該電商網(wǎng)站發(fā)展速度很快，運(yùn)營(yíng)人員感覺(jué)到百度統(tǒng)計(jì)提供的采集數(shù)據(jù)在已經(jīng)無(wú)法滿足當(dāng)前網(wǎng)站的規(guī)模。運(yùn)營(yíng)人員和產(chǎn)品經(jīng)理商量后決定，數(shù)據(jù)采集平臺(tái)需要從百度統(tǒng)計(jì)切換到神策數(shù)據(jù)，神策數(shù)據(jù)提供的埋點(diǎn)接口格式如下：

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

接口的規(guī)則不同，就意味著你需要將幾十個(gè)百度統(tǒng)計(jì)的_htm.push接口更改成為神策提供的sa.track接口。其實(shí)不用這么麻煩，寫一個(gè)適配器就可以完成所有埋點(diǎn)事件的遷移：

//app.js

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

    sa.track(eventName, attrObj);
  }
}

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

有的情況下一個(gè)方法可能需要傳入多個(gè)參數(shù)，例如在SDK這個(gè)類中有一個(gè)phoneStatus，需要傳入五個(gè)參數(shù)用于接收手機(jī)的相關(guān)信息：

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

    //dosomething.....
  }
}

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

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

可以看出，carrier、language，network這三個(gè)屬性不是必須傳入的，它們?cè)诜椒▋?nèi)部可能被設(shè)置一些默認(rèn)值。所以這個(gè)時(shí)候我們就可以在方法內(nèi)部采用適配器來(lái)適配這個(gè)參數(shù)對(duì)象。

class SDK {
  phoneStatus(config) {
    
    let defaultConfig = {
      brand: null,  //手機(jī)品牌
      os: null, //系統(tǒng)類型： Andoird或 iOS
      carrier: "china-mobile", //運(yùn)營(yíng)商，默認(rèn)中國(guó)移動(dòng)
      language: "zh", //語(yǔ)言類型，默認(rèn)中文
      network: "wifi", //網(wǎng)絡(luò)類型，默認(rèn)wifi
    }
    
    //參數(shù)適配
    for( let i in config) {
      defaultConfig[i] = config[i] || defaultConfig[i];
    }
    
    //dosomething.....
  }
}

數(shù)據(jù)的適配在前端中是最為常見(jiàn)的場(chǎng)景，這時(shí)適配器在解決前后端的數(shù)據(jù)依賴上有著重要的意義。通常服務(wù)器端傳遞的數(shù)據(jù)和我們前端需要使用的數(shù)據(jù)格式是不一致的，特別是在在使用一些UI框架時(shí)，框架所規(guī)定的數(shù)據(jù)有著固定的格式。所以，這個(gè)時(shí)候我們就需要對(duì)后端的數(shù)據(jù)格式進(jìn)行適配。

例如網(wǎng)頁(yè)中有一個(gè)使用Echarts折線圖對(duì)網(wǎng)站每周的uv，通常后端返回的數(shù)據(jù)格式如下所示：

[
  {
    "day": "周一",
    "uv": 6300
  },
  {
    "day": "周二",
    "uv": 7100
  },  {
    "day": "周三",
    "uv": 4300
  },  {
    "day": "周四",
    "uv": 3300
  },  {
    "day": "周五",
    "uv": 8300
  },  {
    "day": "周六",
    "uv": 9300
  }, {
    "day": "周日",
    "uv": 11300
  }
]

但是Echarts需要的x軸的數(shù)據(jù)格式和坐標(biāo)點(diǎn)的數(shù)據(jù)是長(zhǎng)下面這樣的:

["周二", "周二", "周三"， "周四"， "周五"， "周六"， "周日"] //x軸的數(shù)據(jù)

[6300. 7100, 4300, 3300, 8300, 9300, 11300] //坐標(biāo)點(diǎn)的數(shù)據(jù)

所以這是我們就可以使用一個(gè)適配器，將后端的返回?cái)?shù)據(jù)做適配：

//x軸適配器
function echartXAxisAdapter(res) {
  return res.map(item => item.day);
}

//坐標(biāo)點(diǎn)適配器
function echartDataAdapter(res) {
  return res.map(item => item.uv);
}

適配器模式在JS中的使用場(chǎng)景很多，在參數(shù)的適配上，有許多庫(kù)和框架都使用適配器模式；數(shù)據(jù)的適配在解決前后端數(shù)據(jù)依賴上十分重要。但是適配器模式本質(zhì)上是一個(gè)亡羊補(bǔ)牢的模式，它解決的是現(xiàn)存的兩個(gè)接口之間不兼容的問(wèn)題，你不應(yīng)該在軟件的初期開(kāi)發(fā)階段就使用該模式；如果在設(shè)計(jì)之初我們就能夠統(tǒng)籌的規(guī)劃好接口的一致性，那么適配器就應(yīng)該盡量減少使用。

[1] 張榮銘 JavaScript設(shè)計(jì)模式 [M].人民郵電出版社

[2] 程杰 大話設(shè)計(jì)模式 [M].清華大學(xué)出版社

[3] 曾探 JavaScript設(shè)計(jì)模式與開(kāi)發(fā)實(shí)踐 [M].r人民郵電出版社