JavaScript设计模式——适配器模式

　　适配器模式是设计模式行为型模式中的一种模式；

　　定义：

　　白话解释：

　　　你买了某种电器产品，准备带回家好好感受该款产品的魅力；结果带回家之后准备通电使用的时候，发现该产品仅支持两孔插座，而你家里的电源插座都是三孔插座；这个时候你总不能又跑去电器专卖店退货吧；突然灵机一动，你想起来了家里还有多功能电源插座，而多功能电源插座恰好就是三孔，于是你拿出你的多功能电源插座插上电源插座，再拿你电器产品的电源插座插在多功能插座上面的两孔插座上，开始享受美滋滋的生活；这里的多功能插座就是一个适配器；

　　代码实现：

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()这个方法了；

　　使用适配器模式来修改：

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的时候调用我们的适配器即可达到预期效果；

　　我们作为前端开发人员，对页面上期待得到的数据和数据格式肯定是比较了解的，但是在前后端分离的开发模式中有的时候会遇到这种尴尬的处境：

　　我们都知道很多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所需要的数据格式进行格式化处理即可解决问题；这两个方法其实就是一个适配器，把指定的数据丢进去即可按照指定规则输出我们期待得到的数据格式；

　　总结：

　　　个人认为适配器模式其实是一种亡羊补牢式的设计模式，如果在项目开发的开始阶段我们就知道我们期待的数据格式或者方法名等，我们就可能永远都用不到适配器模式；但是项目的迭代往往是不可预期的，当项目迭代之后数据格式或者方法名发生变化之后，我们通常可以使用适配器模式来进行适配解决；当然了，最好的解决办法就是项目开发过程中前后端协商讨论数据格式、文件名等代码规范，这样是对项目的开发效率是会有很大的提升的；