本篇文章給大家分享的是有關(guān)適配器在JavaScript中的體現(xiàn)是怎么樣的，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

目前成都創(chuàng)新互聯(lián)已為上1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站運(yùn)營(yíng)、企業(yè)網(wǎng)站設(shè)計(jì)、吐魯番網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

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

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

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

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

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

生活中的例子

在生活中最常見(jiàn)的就是電源插頭的適配器了，世界各國(guó)的插座標(biāo)準(zhǔn)各不相同，如果需要根據(jù)各國(guó)的標(biāo)準(zhǔn)購(gòu)買對(duì)應(yīng)的電源插頭那未免太過(guò)于浪費(fèi)錢財(cái)，如果說(shuō)自己帶著插座，把人家墻敲碎，重新接線，也肯定是不現(xiàn)實(shí)的。

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

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

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

將那些你不愿意看見(jiàn)的臟代碼藏起來(lái)，你就可以說(shuō)這是一個(gè)適配器

接入多個(gè)第三方SDK

舉個(gè)日常開(kāi)發(fā)中的例子，我們?cè)谧鲆粋€(gè)微信公眾號(hào)開(kāi)發(fā)，里邊用到了微信的支付模塊，經(jīng)過(guò)長(zhǎng)時(shí)間的聯(lián)調(diào)，終于跑通了整個(gè)流程，正當(dāng)你準(zhǔn)備開(kāi)心的打包上線代碼的時(shí)候，得到了一個(gè)新需求：

我們需要接入支付寶公眾號(hào)的SDK，也要有支付的流程

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

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

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

所以針對(duì)上述的代碼可能是這樣的：

// 并不是真實(shí)的參數(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    })  }

就目前來(lái)說(shuō)，代碼接口還算是清晰，只要我們寫好注釋，這也不是一個(gè)太糟糕的代碼。

但是生活總是充滿了意外，我們又接到了需求需要添加QQ的SDK、美團(tuán)的SDK、小米的SDK，或者某些銀行的SDK。

此時(shí)你的代碼可能是這樣的：

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

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

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

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

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

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

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

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

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

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

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

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

一些其他的例子

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

一步步的進(jìn)行降級(jí)，并且抹平了一些瀏覽器之間的差異，讓我們可以通過(guò)簡(jiǎn)單的on來(lái)進(jìn)行在主流瀏覽器中進(jìn)行事件監(jiān)聽(tīng)：

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

或者在Node中的這樣的例子更是常見(jiàn)，因?yàn)樵缒晔菦](méi)有Promise的，所以大多數(shù)的異步由callback來(lái)完成，且有一個(gè)約定好的規(guī)則，Error-first callback：

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

而我們的新功能都采用了async/await的方式來(lái)進(jìn)行，當(dāng)我們需要復(fù)用一些老項(xiàng)目中的功能時(shí)，直接去修改老項(xiàng)目的代碼肯定是不可行的。

這樣的兼容處理需要調(diào)用方來(lái)做，所以為了讓邏輯代碼看起來(lái)不是太混亂，我們可能會(huì)將這樣的回調(diào)轉(zhuǎn)換為Promise的版本方便我們進(jìn)行調(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')

因?yàn)榍斑呉蔡岬搅?，這種Error-first callback是一個(gè)約定好的形式，所以我們可以很輕松的實(shí)現(xiàn)一個(gè)通用的適配器：

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

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

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

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

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

因?yàn)闀兴f(shuō)的場(chǎng)景可能并不全面，也可能針對(duì)某些語(yǔ)言，會(huì)存在更好的解決辦法，所以生搬硬套可能并不會(huì)寫出有靈魂的代碼 。

以上就是適配器在JavaScript中的體現(xiàn)是怎么樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。