JavaScript에서 어댑터 적용(예제 포함)

이 기사의 내용은 JavaScript에서 어댑터를 적용하는 방법에 대한 것입니다(예제 포함). 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

어댑터 디자인 패턴은 JavaScript에서 매우 유용합니다. 이는 브라우저 간 호환성 문제를 처리하고 여러 타사 SDK의 호출을 통합하는 데 사용할 수 있습니다.
사실 일상적인 개발에서 우리는 무심코 특정 디자인 패턴에 맞는 코드를 작성하는 경우가 많습니다. 결국 디자인 패턴은 개발 효율성을 높이는 데 도움이 될 수 있는 선배들이 요약하고 다듬은 템플릿이며 일상적인 개발에서 비롯됩니다.
사실 어댑터는 JavaScript에서 상대적으로 일반적인 것이어야 합니다.

Wikipedia에서 어댑터 패턴의 정의는 다음과 같습니다.

소프트웨어 엔지니어링에서 어댑터 패턴은 기존 클래스의 인터페이스를 다른 인터페이스에서 사용할 수 있도록 하는 소프트웨어 디자인 패턴입니다. 소스 코드를 수정하지 않고 기존 클래스가 다른 클래스와 작동하도록 만드는 데 자주 사용됩니다.

생활 속의 예

생활에서 가장 흔한 것은 전원 플러그 어댑터입니다. 세계 각국의 소켓 표준은 다릅니다. 각 국가의 표준에 따라 해당 전원 플러그를 구입해야 한다면, 자신의 소켓을 가져와서 다른 사람의 벽을 허물고 다시 배선하는 것은 확실히 비현실적입니다.
한 종류의 플러그를 다른 종류의 플러그로 변환하는 데 사용되는 플러그 어댑터가 있습니다. 소켓과 전원 공급 장치 간의 전송 역할을 하는 것이 바로 어댑터입니다.

은 코드에 반영됩니다.

프로그래밍에 관해서는 개인적으로 이렇게 이해합니다.

연결 여러 타사 SDK 통합

일상적인 개발의 예로 WeChat의 결제 모듈을 사용하는 WeChat 공개 계정을 개발하고 있습니다. 오랜 기간의 공동 디버깅 끝에 마침내 전체 프로세스를 진행했습니다. 행복하게 코드를 패키징하고 실행했을 때 새로운 요구 사항이 생겼습니다.
Alipay 공식 계정의 SDK에 액세스하고 결제 프로세스가 필요합니다.

코드를 재사용하려면 다음과 같이 작성할 수 있습니다. in the script Logic:

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, Meituan의 SDK, Xiaomi의 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를 통합하는 작업은 어댑터에 맡겨집니다. 그런 다음 어댑터 코드를 압축하고 난독화하여 보이지 않는 모서리에 배치하므로 코드 로직이 매우 명확해집니다. :) .

어댑터의 역할은 대략 이렇습니다. 어댑터는 만능이 아닙니다. __이러한 지루한 코드는 항상 존재하지만 비즈니스를 작성할 때는 눈에 띄지 않습니다.

다른 예

개인적으로는 가장 기본적인 $('selector').on을 포함하여 jQuery에 어댑터의 예가 많이 있다고 생각합니다. 이것이 명백한 어댑터 패턴입니까? 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')

小结

个人观点：所有的设计模式都不是凭空想象出来的，肯定是在开发的过程中，总结提炼出的一些高效的方法，这也就意味着，可能你并不需要在刚开始的时候就去生啃这些各种命名高大上的设计模式。  
因为书中所说的场景可能并不全面，也可能针对某些语言，会存在更好的解决办法，所以生搬硬套可能并不会写出有灵魂的代码 :)

위 내용은 JavaScript에서 어댑터 적용(예제 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!