適配器在JavaScript中的體現

適配器設計模式在JavaScript中很是有用，在處理跨瀏覽器兼容問題、整合多個第三方SDK的調用，均可以看到它的身影。
其實在平常開發中，不少時候會不經意間寫出符合某種設計模式的代碼，畢竟設計模式就是老前輩們總結提煉出來的一些可以幫助提高開發效率的一些模版，源於平常的開發中。
而適配器其實在JavaScript中應該是比較常見的一種了。

在維基百科中，關於適配器模式的定義爲：

在軟件工程中，適配器模式是一種軟件設計模式，容許從另外一個接口使用現有類的接口。它一般用於使現有的類與其餘類一塊兒工做，而無需修改其源代碼。

生活中的例子

在生活中最多見的就是電源插頭的適配器了，世界各國的插座標準各不相同，若是須要根據各國的標準購買對應的電源插頭那未免太過於浪費錢財，若是說本身帶着插座，把人家牆敲碎，從新接線，也確定是不現實的。
因此就會有插頭的適配器，用來將某種插頭轉換成另外一種插頭，在插座和你的電源之間作中轉的這個東西，就是適配器。

在代碼中的體現

而轉向到編程中，我我的是這樣理解的：

將那些你不肯意看見的髒代碼藏起來，你就能夠說這是一個適配器

接入多個第三方SDK

舉個平常開發中的例子，咱們在作一個微信公衆號開發，裏邊用到了微信的支付模塊，通過長時間的聯調，終於跑通了整個流程，正當你準備開心的打包上線代碼的時候，獲得了一個新需求：
咱們須要接入支付寶公衆號的SDK，也要有支付的流程

爲了複用代碼，咱們可能會在腳本中寫下這樣的邏輯：

if (platform === 'wechat') {
  wx.pay(config)
} else if (platform === 'alipay') {
  alipay.pay(config)
}

// 作一些後續的邏輯處理

可是通常來講，各廠的SDK所提供的接口調用方式都會多多少少有些區別，雖然說有些時候文檔可能用的是同一份，致敬友商。

因此針對上述的代碼多是這樣的：

// 並非真實的參數配置，僅僅舉例使用
const config = {
  price: 10,
  goodsId: 1
}

// 還有可能返回值的處理方式也不相同
if (platform === 'wechat') {
  config.appId = 'XXX'
  config.secretKey = 'XXX'
  wx.pay(config).then((err, data) => {
    if (err) // error

    // success
  })
} else if (platform === 'alipay') {
  config.token = 'XXX'
  alipay.pay(config, data => {
    // success
  }, err => {
    // error
  })
}

就目前來講，代碼接口還算是清晰，只要咱們寫好註釋，這也不是一個太糟糕的代碼。
可是生活老是充滿了意外，咱們又接到了需求須要添加QQ的SDK、美團的SDK、小米的SDK，或者某些銀行的SDK。

此時你的代碼多是這樣的：

switch (platform) {
  case 'wechat':
    // 微信的處理邏輯
  break
  case 'QQ':
    // QQ的處理邏輯
  break
  case 'alipay':
    // 支付寶的處理邏輯
  break
  case 'meituan':
    // 美團的處理邏輯
  break
  case 'xiaomi':
    // 小米的處理邏輯
  break
}

這已經不是一些註釋可以彌補的問題了，這樣的代碼會變得愈來愈難維護，各類SDK千奇百怪的調用方式，若是其餘人也要作相似的需求，還須要從新寫一遍這樣的代碼，那確定是很浪費資源的一件事兒。

因此爲了保證咱們業務邏輯的清晰，同時也爲了不後人重複的踩這個坑，咱們會將它進行拆分出來做爲一個公共的函數來存在：
找到其中某一個SDK的調用方式或者一個咱們約定好的規則做爲基準。
咱們來告訴調用方，你要怎麼怎麼作，你能怎樣獲取返回數據，而後咱們在函數內部進行這些各類骯髒的判斷：

function pay ({
  price,
  goodsId
}) {
  return new Promise((resolve, reject) => {
    const config = {}

    switch (platform) {
      case 'wechat':
        // 微信的處理邏輯
        config.price = price
        config.goodsId = goodsId
        config.appId = 'XXX'
        config.secretKey = 'XXX'
        wx.pay(config).then((err, data) => {
          if (err) return reject(err)

          resolve(data)
        })
      break
      case 'QQ':
        // QQ的處理邏輯
        config.price = price * 100
        config.gid = goodsId
        config.appId = 'XXX'
        config.secretKey = 'XXX'
        config.success = resolve
        config.error = reject
        qq.pay(config)
      break
      case 'alipay':
        // 支付寶的處理邏輯
        config.payment = price
        config.id = goodsId
        config.token = 'XXX'
        alipay.pay(config, resolve, reject)
      break
    }
  })
}

這樣不管咱們在什麼環境下，只要咱們的適配器支持，就能夠按照咱們約定好的通用規則進行調用，而具體執行的是什麼SDK，則是適配器須要關心的事情：

// run anywhere
await pay({
  price: 10,
  goodsId: 1
})

對於SDK提供方，僅僅須要知道本身所須要的一些參數，而後按照本身的方式進行數據返回。
對於SDK調用房，僅僅須要咱們約定好的通用的參數，以及按照約定的方式進行監聽回調處理。

整合多個第三方SDK的任務就交由適配器來作，而後咱們將適配器的代碼壓縮，混淆，放在一個看不見的角落裏去，這樣的代碼邏輯就會變得很清晰了 :)。

適配器大體就是這樣的做用，有一點必定要明確，適配器不是銀彈，__那些繁瑣的代碼始終是存在的，只不過你在寫業務的時候看不到它罷了__，眼不見心不煩。

一些其餘的例子

我的以爲，jQuery中就有不少適配器的例子，包括最基礎的$('selector').on，這個不就是一個很明顯的適配器模式麼？

一步步的進行降級，而且抹平了一些瀏覽器之間的差別，讓咱們能夠經過簡單的on來進行在主流瀏覽器中進行事件監聽：

// 一個簡單的僞代碼示例
function on (target, event, callback) {
  if (target.addEventListener) {
    // 標準的監聽事件方式
    target.addEventListener(event, callback)
  } else if (target.attachEvent) {
    // IE低版本的監聽方式
    target.attachEvent(event, callback)
  } else {
    // 一些低版本的瀏覽器監聽事件方式
    target[`on${event}`] = callback
  }
}

或者在Node中的這樣的例子更是常見，由於早年是沒有Promise的，因此大多數的異步由callback來完成，且有一個約定好的規則，Error-first callback：

const fs = require('fs')

fs.readFile('test.txt', (err, data) => {
  if (err) // 處理異常

  // 處理正確結果
})

而咱們的新功能都採用了async/await的方式來進行，當咱們須要複用一些老項目中的功能時，直接去修改老項目的代碼確定是不可行的。
這樣的兼容處理須要調用方來作，因此爲了讓邏輯代碼看起來不是太混亂，咱們可能會將這樣的回調轉換爲Promise的版本方便咱們進行調用：

const fs = require('fs')

function readFile (fileName) {
  return new Promise((resolve, reject) => {
    fs.readFile(fileName, (err, data) => {
      if (err) reject(err)

      resolve(data)
    })
  })
}

await readFile('test.txt')

由於前邊也提到了，這種Error-first callback是一個約定好的形式，因此咱們能夠很輕鬆的實現一個通用的適配器：

function promisify(func) {
  return (...args) => new Promise((resolve, reject) => {
    func(...args, (err, data) => {
      if (err) reject(err)

      resolve(data)
    })
  })
}

而後在使用前進行對應的轉換就能夠用咱們預期的方式來執行代碼：

const fs = require('fs')

const readFile = promisify(fs.readFile)

await readFile('test.txt')

在Node8中，官方已經實現了相似這樣的工具函數： util.promisify

小結

我的觀點：全部的設計模式都不是憑空想象出來的，確定是在開發的過程當中，總結提煉出的一些高效的方法，這也就意味着，可能你並不須要在剛開始的時候就去生啃這些各類命名高大上的設計模式。
由於書中所說的場景可能並不全面，也可能針對某些語言，會存在更好的解決辦法，因此生搬硬套可能並不會寫出有靈魂的代碼 :)

紙上得來終覺淺，絕知此事要躬行。 ———— 《冬夜讀書示子聿》，陸游