适配器模式是设计模式行为型模式中的一种模式;前端
定义:json
适配器用来解决两个已有接口之间不匹配的问题,它并不须要考虑接口是如何实现,也不用考虑未来该如何修改;适配器不须要修改已有接口,就可使他们协同工做;后端
白话解释:设计模式
你买了某种电器产品,准备带回家好好感觉该款产品的魅力;结果带回家以后准备通电使用的时候,发现该产品仅支持两孔插座,而你家里的电源插座都是三孔插座;这个时候你总不能又跑去电器专卖店退货吧;忽然灵机一动,你想起来了家里还有多功能电源插座,而多功能电源插座刚好就是三孔,因而你拿出你的多功能电源插座插上电源插座,再拿你电器产品的电源插座插在多功能插座上面的两孔插座上,开始享受美滋滋的生活;这里的多功能插座就是一个适配器;
echarts
代码实现:前后端分离
var googleMap = { show: function(){ console.log( '开始渲染谷歌地图' ); } }; var baiduMap = { show: function(){ console.log( '开始渲染百度地图' ); } }; var renderMap = function( map ){ if ( map.show instanceof Function ){ map.show(); } }; renderMap( googleMap ); // 开始渲染谷歌地图 renderMap( baiduMap ); // 开始渲染百度地图
固然上面的代码是可以正常运行的,这得益于这两个对象中的参数名都是同样的,因此才可以正常的运行和显示;函数
var googleMap = { show: function(){ console.log( '开始渲染谷歌地图' ); } }; var baiduMap = { display: function(){ console.log( '开始渲染百度地图' ); } };
忽然有一天若是baiduMap的方法名改变了呢?那么咱们再跟上面同样运行确定是会报错的,由于baiduMap对象中已经没有了show()这个方法了;工具
使用适配器模式来修改:google
var googleMap = { show: function(){ console.log( '开始渲染谷歌地图' ); } }; var baiduMap = { display: function(){ console.log( '开始渲染百度地图' ); } }; var baiduMapAdapter = { show: function(){ return baiduMap.display(); } }; renderMap( googleMap ); // 开始渲染谷歌地图 renderMap( baiduMapAdapter ); // 开始渲染百度地图
在这段代码中适配器作的事情其实很简单,就是建立了一个对象,添加了一个同名的show()方法,而后在适配器里面调用了baiduMap.display()方法,这样咱们只须要在调用baiduMap的时候调用咱们的适配器便可达到预期效果;
spa
咱们做为前端开发人员,对页面上期待获得的数据和数据格式确定是比较了解的,可是在先后端分离的开发模式中有的时候会遇到这种尴尬的处境:
咱们都知道不少UI组件或者工具库会按指定的数据格式进行渲染,可是这个时候后端是不知道的;因此可能接口出来的数据咱们是不能直接正常的在页面上渲染的,而此时老板催促咱们赶忙上线,然后端坚持认为数据格式没问题,坚定不修改;这个时候咱们能够经过适配器模式来前端格式化数据;
后端返回的json数据格式:
[ { "day": "周一", "uv": 6300 }, { "day": "周二", "uv": 7100 }, { "day": "周三", "uv": 4300 }, { "day": "周四", "uv": 3300 }, { "day": "周五", "uv": 8300 }, { "day": "周六", "uv": 9300 }, { "day": "周日", "uv": 11300 } ]
Echarts图表图形须要的数据格式:
["周二", "周二", "周三", "周四", "周五", "周六", "周日"] //x轴的数据 [6300. 7100, 4300, 3300, 8300, 9300, 11300] //坐标点的数据
虽然内心苦,但仍是要解决问题!使用适配器来解决:
//x轴适配器 function echartXAxisAdapter(res) { return res.map(item => item.day); } //坐标点适配器 function echartDataAdapter(res) { return res.map(item => item.uv); }
建立两个函数分别对数据按照echarts所须要的数据格式进行格式化处理便可解决问题;这两个方法其实就是一个适配器,把指定的数据丢进去便可按照指定规则输出咱们期待获得的数据格式;
总结:
我的认为适配器模式实际上是一种亡羊补牢式的设计模式,若是在项目开发的开始阶段咱们就知道咱们期待的数据格式或者方法名等,咱们就可能永远都用不到适配器模式;可是项目的迭代每每是不可预期的,当项目迭代以后数据格式或者方法名发生变化以后,咱们一般可使用适配器模式来进行适配解决;固然了,最好的解决办法就是项目开发过程当中先后端协商讨论数据格式、文件名等代码规范,这样是对项目的开发效率是会有很大的提高的;