适配器模式是设计模式行为型模式中的一种模式;
定义:
适配器用来解决两个已有接口之间不匹配的问题,它并不需要考虑接口是如何实现,也不用考虑将来该如何修改;适配器不需要修改已有接口,就可以使他们协同工作;
白话解释:
你买了某种电器产品,准备带回家好好感受该款产品的魅力;结果带回家之后准备通电使用的时候,发现该产品仅支持两孔插座,而你家里的电源插座都是三孔插座;这个时候你总不能又跑去电器专卖店退货吧;突然灵机一动,你想起来了家里还有多功能电源插座,而多功能店员插座恰好就是三孔,于是你拿出你的多功能电源插座插上电源插座,再拿你电器产品的电源插座插在多功能插座上面的两孔插座上,开始享受美滋滋的生活;这里的多功能插座就是一个适配器;
代码实现:
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所需要的数据格式进行格式化处理即可解决问题;这两个方法其实就是一个适配器,把指定的数据丢进去即可按照指定规则输出我们期待得到的数据格式;
总结:
个人认为适配器模式其实是一种亡羊补牢式的设计模式,如果在项目开发的开始阶段我们就知道我们期待的数据格式或者方法名等,我们就可能永远都用不到适配器模式;但是项目的迭代往往是不可预期的,当项目迭代之后数据格式或者方法名发生变化之后,我们通常可以使用适配器模式来进行适配解决;当然了,最好的解决办法就是项目开发过程中前后端协商讨论数据格式、文件名等代码规范,这样是对项目的开发效率是会有很大的提升的;
单例模式是我们开发中一个非常典型的设计模式,js单例模式要保证全局只生成唯一实例,提供一个单一的访问入口,单例的对象不同于静态类,我们可以延迟单例对象的初始化,通常这种情况发生在我们需要等待加载创建单例的依赖。
工厂模式下的对象我们不能识别它的类型,由于typeof返回的都是object类型,不知道它是那个对象的实例。另外每次造人时都要创建一个独立的person的对象,会造成代码臃肿的情况。
建造者模式:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。工厂类模式提供的是创建单个类的模式,而建造者模式则是将各种产品集中起来进行管理,用来创建复合对象
主要涉及知识点: HTML与XHTML,HTML与XHTML的区别,DOCTYPE与DTD的概念,DTD的分类以及DOCTYPE的声明方式,标准模式(Standard Mode)和兼容模式(Quircks Mode),标准模式(Standard Mode)和兼容模式(Quircks Mode)的区别
JavaScript中常见的四种设计模式:工厂模式、单例模式、沙箱模式、发布者订阅模式
javascript 策略模式的定义是:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。 策略模式利用组合,委托等技术和思想,有效的避免很多if条件语句,策略模式提供了开放-封闭原则,使代码更容易理解和扩展, 策略模式中的代码可以复用。
javascript观察者模式又叫发布订阅模式,观察者模式的好处:js观察者模式支持简单的广播通信,自动通知所有已经订阅过的对象。存在一种动态关联,增加了灵活性。目标对象与观察者之间的抽象耦合关系能够单独扩展以及重用。
熟悉 Vue 的都知道 方法methods、计算属性computed、观察者watcher 在 Vue 中有着非常重要的作用,有些时候我们实现一个功能的时候可以使用它们中任何一个都是可以的
我觉得聊一下我爱用的 JavaScript 设计模式应该很有意思。我是一步一步才定下来的,经过一段时间从各种来源吸收和适应直到达到一个能提供我所需的灵活性的模式。让我给你看看概览,然后再来看它是怎么形成的
在围绕设计模式的话题中,工厂这个词频繁出现,从 简单工厂 模式到 工厂方法 模式,再到 抽象工厂 模式。工厂名称含义是制造产品的工业场所,应用在面向对象中,顺理成章地成为了比较典型的创建型模式
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!