详细说明适配器在JavaScript中的体现

适配器设计模式在JavaScript中非常有用，在处理跨浏览器兼容性问题和集成来自多个第三方SDK的调用时可以看到这一点。

事实上，在日常开发中，我们经常会不经意地编写符合某些设计模式的代码。毕竟，设计模式是一些由老前辈总结和提炼的模板，用来帮助提高开发效率，源于日常开发。

事实上，适配器应该是JavaScript中常见的一种。

在维基百科中，适配器模式的定义是：

在软件工程中，适配器模式是一种软件设计模式，它允许从另一个接口使用现有类的接口。它通常用于使现有的类与其他类一起工作，而不修改它们的源代码。

生活中的例子

电源插头的适配器是生活中最常见的一种。插座标准因国家而异。根据不同国家的标准购买相应的电源插头是浪费钱的。说你带了插座，打破人家的墙，重新连接，肯定是不现实的。

因此，会有一个插头适配器，用于将一个插头转换成另一个插头。在插座和电源之间传递的是适配器。

体现在代码中

谈到编程，我个人理解这一点：

隐藏不想看到的脏代码，可以说是适配器

访问多个第三方软件开发工具包

举一个日常开发的例子，我们在做一个微信微信官方账号开发，使用的是微信的支付模块。经过长时间的联合调试，我们终于跑完全程了。就在你准备开心打包网上代码的时候，我们得到了一个新的需求：我们需要接入支付宝微信官方账号的SDK，还要有一个支付流程

为了重用代码，我们可以在脚本中编写这样的逻辑：

If (platform=='微信'){ wx . pay(config)} else if(platform==' Alipay '){ Alipay . pay(config)}//做一些后续的逻辑处理，但是一般来说，每个工厂的SDK提供的接口调用方式或多或少都是不一样的，虽然有时候可能会用到同一个文档。

因此，上面的代码可能如下所示：

//不是实参数配置，只是以const config={ price : 10 }为例。GoodsId: 1}//如果(platform=='微信'){ config . appid=' XXX ' config . secrettkey=' XXX ' wx . pay(config)，返回值的处理方式也有可能不同。然后((err，Data)={ if(err)//error//success })} else if(platform==='支付宝'){config。代币=' XXX '支付宝。支付(配置，数据={//成功}，错误={//错误})}目前，

但是生活总是充满意外，我们收到过QQ的SDK，美团的SDK，小米的SDK，或者一些银行的SDK。

此时，您的代码可能如下所示：

Switch(平台){case '微信' : //微信处理逻辑断格' QQ': //QQ处理逻辑断格'支付宝' : //支付宝处理逻辑断格'美团' : //美团的处理逻辑断格'小米' ://小米的处理逻辑断格}这已经不是一些注解可以补救的问题了。这样的代码将变得越来越难以维护。SDK有各种奇怪的调用方法。如果其他人想提出类似的要求，就需要重写这样的代码，这绝对是资源的浪费。

因此，为了保证我们业务逻辑的清晰，同时避免后人反复踩这个坑，我们将它拆分为一个公共功能来存在：

找到其中一个SDK的调用方法或者我们约定的规则作为基准。

让我们告诉调用者您想要做什么，以及如何获取返回的数据，然后我们在函数内部做出这些肮脏的判断：

函数pay ({ price，good id }){ return new Promise((resolve，reject)={ const config={ } switch(platform){ case '微信' : //微信处理逻辑config . price=price config . good id=good id config . appid=' XXX ' config . secrettkey=' XXX ' wx . pay(config)。然后(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 . pay(config)Break case '支付宝' ://支付宝处理逻辑config . payment=price config . id=goodsId config . token=' XXX '支付宝我们可以根据我们商定的一般规则来调用它，而SDK具体实现的是适配器需要关心的事情：

//anywhere run await pay({ price : 10，goodsid : 1 })对于SDK提供者来说，他们只需要知道自己需要的一些参数，然后以自己的方式返回数据。

对于SDK调用方，我们只需要约定的通用参数，并以约定的方式监听和回叫。

集成多个第三方SDK的任务交给适配器，然后我们把适配器的代码压缩、混淆，放到一个看不见的角落，这样代码逻辑就会变得清晰。

这大致就是适配器的作用。有一点必须明确：适配器不是银弹。_ _那些繁琐的代码一直存在，但是写业务的时候看不到。_ _，眼不见，心不烦。

其他一些例子

个人认为jQuery中有很多适配器的例子，包括最基本的$('selector').on，这不是很明显的适配器模式吗？

逐步降级，并消除了浏览器之间的一些差异，这样我们就可以通过简单的on:

//一个简单的伪代码示例：functionon(目标、事件、回调){if(目标。addevent listener){//监听事件的标准方式是target.addEventListener(event，Callback)} else if (target。attachevent) {//ie，较低版本的监控方法，target.attachEvent(event，Callback)} else {//一些较低版本的浏览器监听事件模式target[` on $ { event } `]=Callback } }或者Node中这样的例子比较常见，因为早期没有Promise，所以大部分异步都是通过回调来完成的，有一个约定的规则，Error-first callback:

const fs=require(' fs ')fs . read file(' test . txt '，(err，data)={ if(err)//处理异常//处理正确的结果})，我们的新功能都是在异步/等待模式下执行的。当我们需要重用旧项目中的一些函数时，肯定需要直接修改旧项目的代码，这样的兼容处理需要调用者去做，所以为了让逻辑代码看起来不太混乱，我们可能会把这样的回调转换成Promise版本让我们调用：

const fs=require('fs ')函数readFile(fileName){ return new Promise((resolve，reject)={ fs.readFile(fileName，(err，Data)={ if(err)reject(err)resolve(Data)})} } await readFile(' test . txt ')如前所述，这种错误优先回调是一种常规形式，因此我们可以轻松实现一个通用适配器：

函数promisify (func) {return(.args)=newpromise((解析，拒绝)={func(.args，(err，data)={ if(err)reject(err)resolve(data)} } }然后在使用之前执行相应的转换

const fs=require(' fs ')const readfile=promisify(fs . readfile)wait readfile(' test . txt ')在Node8中，官方实现了一个类似util.promisify的工具函数

摘要

个人观点：所有的设计模式都不是凭空想象出来的，但是一些高效的方法必须在开发过程中进行总结和提炼，这就意味着你可能不需要一开始就去啃这些名字很高的设计模式。

因为书中提到的场景可能不全面，对于某些语言可能有更好的解决方案，所以用soul写代码可能不太可能。

以上就是边肖介绍的适配器在JavaScript中的体现。希望对大家有帮助。如果你有任何问题，请给我留言，边肖会及时回复你。非常感谢您对我们网站的支持！