適配器設(shè)計模式在JavaScript中非常有用，在處理跨瀏覽器兼容問題、整合多個第三方SDK的調(diào)用，都可以看到它的身影。

其實在日常開發(fā)中，很多時候會不經(jīng)意間寫出符合某種設(shè)計模式的代碼，畢竟設(shè)計模式就是老前輩們總結(jié)提煉出來的一些能夠幫助提升開發(fā)效率的一些模版，源于日常的開發(fā)中。

而適配器其實在JavaScript中應(yīng)該是比較常見的一種了。

在維基百科中，關(guān)于適配器模式的定義為：

在軟件工程中，適配器模式是一種軟件設(shè)計模式，允許從另一個接口使用現(xiàn)有類的接口。它通常用于使現(xiàn)有的類與其他類一起工作，而無需修改其源代碼。

生活中的例子

在生活中最常見的就是電源插頭的適配器了，世界各國的插座標準各不相同，如果需要根據(jù)各國的標準購買對應(yīng)的電源插頭那未免太過于浪費錢財，如果說自己帶著插座，把人家墻敲碎，重新接線，也肯定是不現(xiàn)實的。

所以就會有插頭的適配器，用來將某種插頭轉(zhuǎn)換成另一種插頭，在插座和你的電源之間做中轉(zhuǎn)的這個東西，就是適配器。

在代碼中的體現(xiàn)

而轉(zhuǎn)向到編程中，我個人是這樣理解的：

將那些你不愿意看見的臟代碼藏起來，你就可以說這是一個適配器

接入多個第三方SDK

舉個日常開發(fā)中的例子，我們在做一個微信公眾號開發(fā)，里邊用到了微信的支付模塊，經(jīng)過長時間的聯(lián)調(diào)，終于跑通了整個流程，正當你準備開心的打包上線代碼的時候，得到了一個新需求：
我們需要接入支付寶公眾號的SDK，也要有支付的流程

為了復(fù)用代碼，我們可能會在腳本中寫下這樣的邏輯：

if (platform === 'wechat') {
 wx.pay(config)
} else if (platform === 'alipay') {
 alipay.pay(config)
}
// 做一些后續(xù)的邏輯處理

但是一般來說，各廠的SDK所提供的接口調(diào)用方式都會多多少少有些區(qū)別，雖說有些時候文檔可能用的是同一份，致敬友商。

所以針對上述的代碼可能是這樣的：

// 并不是真實的參數(shù)配置，僅僅舉例使用
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
}

這已經(jīng)不是一些注釋能夠彌補的問題了，這樣的代碼會變得越來越難維護，各種SDK千奇百怪的調(diào)用方式，如果其他人也要做類似的需求，還需要重新寫一遍這樣的代碼，那肯定是很浪費資源的一件事兒。

所以為了保證我們業(yè)務(wù)邏輯的清晰，同時也為了避免后人重復(fù)的踩這個坑，我們會將它進行拆分出來作為一個公共的函數(shù)來存在：

找到其中某一個SDK的調(diào)用方式或者一個我們約定好的規(guī)則作為基準。

我們來告訴調(diào)用方，你要怎么怎么做，你能怎樣獲取返回數(shù)據(jù)，然后我們在函數(shù)內(nèi)部進行這些各種骯臟的判斷：

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
 }
 })
}

這樣無論我們在什么環(huán)境下，只要我們的適配器支持，就可以按照我們約定好的通用規(guī)則進行調(diào)用，而具體執(zhí)行的是什么SDK，則是適配器需要關(guān)心的事情：

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

對于SDK提供方，僅僅需要知道自己所需要的一些參數(shù)，然后按照自己的方式進行數(shù)據(jù)返回。

對于SDK調(diào)用方，僅僅需要我們約定好的通用的參數(shù)，以及按照約定的方式進行監(jiān)聽回調(diào)處理。

整合多個第三方SDK的任務(wù)就交由適配器來做，然后我們將適配器的代碼壓縮，混淆，放在一個看不見的角落里去，這樣的代碼邏輯就會變得很清晰了 :)。

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

一些其他的例子

個人覺得，jQuery中就有很多適配器的例子，包括最基礎(chǔ)的$('selector').on，這個不就是一個很明顯的適配器模式么？

一步步的進行降級，并且抹平了一些瀏覽器之間的差異，讓我們可以通過簡單的on來進行在主流瀏覽器中進行事件監(jiān)聽：

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

或者在Node中的這樣的例子更是常見，因為早年是沒有Promise的，所以大多數(shù)的異步由callback來完成，且有一個約定好的規(guī)則，Error-first callback：

const fs = require('fs')
fs.readFile('test.txt', (err, data) => {
 if (err) // 處理異常
 // 處理正確結(jié)果
})

而我們的新功能都采用了async/await的方式來進行，當我們需要復(fù)用一些老項目中的功能時，直接去修改老項目的代碼肯定是不可行的。
這樣的兼容處理需要調(diào)用方來做，所以為了讓邏輯代碼看起來不是太混亂，我們可能會將這樣的回調(diào)轉(zhuǎn)換為Promise的版本方便我們進行調(diào)用：

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是一個約定好的形式，所以我們可以很輕松的實現(xiàn)一個通用的適配器：

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

然后在使用前進行對應(yīng)的轉(zhuǎn)換就可以用我們預(yù)期的方式來執(zhí)行代碼：

const fs = require('fs')
const readFile = promisify(fs.readFile)
await readFile('test.txt')

在Node8中，官方已經(jīng)實現(xiàn)了類似這樣的工具函數(shù)：util.promisify

小結(jié)

個人觀點：所有的設(shè)計模式都不是憑空想象出來的，肯定是在開發(fā)的過程中，總結(jié)提煉出的一些高效的方法，這也就意味著，可能你并不需要在剛開始的時候就去生啃這些各種命名高大上的設(shè)計模式。

因為書中所說的場景可能并不全面，也可能針對某些語言，會存在更好的解決辦法，所以生搬硬套可能并不會寫出有靈魂的代碼 :)

以上所述是小編給大家介紹的適配器在JavaScript中的體現(xiàn)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論