设计模式梳理之适配器模式

适配器模式，将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

适配器概念

• 什么是适配器,还是从名称本事出发去理解,前边我有说过,设计模式的名称其实就是设计模式中心思想的总结,适配器,用来做适配的东西,为什么做适配呢,为原来两个不匹配的东西做适配,方式是怎样的呢,用最形象的一个比喻来说,就是转接头

举个栗子:

我有一个装修良好的屋子,里边设施一应俱全,我开始打扫卫生,借用了一个邻居的吸尘器,邻居很奇葩,是一个极其离谱且无聊的"发明家",邻居自己造了一个吸尘器,用的插头也是自己造的,离谱吧,更离谱的是这个邻居的吸尘器插头,是四插头的,这我就该头疼了,这我咋办啊,我想了一个办法,我给我家各个屋子都装上了四插头,这样我借用的吸尘器就可以到处去插上去使用了,这样一来我是不是解决了这个四插头吸尘器的问题,是的,但是这里就出现了两个问题,第一个就是,我家每个屋子从今天开始都多了一个大概率是不会再用,且看着十分智障的四插头,我自己在家看着糟心,别人看我家也会笑话我

• 四插头问题
  我解释一下这个四插头问题为什么会出现,因为我们现在的开发都是模块化的,且我们做较为简单的要求不太严格的需求的时候会大量的使用第三方的组件,那就会出现这个问题,有可能是正向的,也有可能是反向的,总之很有可能出现,自己的代码很离谱,或者别人的代码很离谱,就算都是正常的,也有可能出现双插头和三插头不匹配的问题,我给每个屋子都装上四插头,也就是说我在我代码原本的逻辑中要加判断,判断东西是不是四插头,是的话要通过四插头的方法去调用去处理,这样的代码,我本人看着丑陋,别人看着恶心

• 如何解决
  丑陋三连:
  1.改自己的代码
  2.复制一份别人的组件代码,手动改别人的代码
  3.找别人吵架,统一代码规范,修改代码
  其实大可不必,我们的适配器模式就是为了解决这种对接问题,给被调用的方法做一个适配器,也就是一层包裹,返回一个满足使用者使用需求的方法

适配器代码举例

//电视机
class Television{
	//电视机的三插头
    threePlugs() {
        console.log('电视机通电了')
    }
}
//吸尘器
class VacuumCleaner{
	//借的吸尘器的奇葩四插头
    fourPlug() {
        console.log('吸尘器通电了')
    }
}
// 定义适配器类,转接头
class Adapter{
    threePlugs() {
        var vacuumCleaner= new VacuumCleaner()
        return vacuumCleaner.fourPlug()
    }
}
//插座
function socket(obj) {
    if (obj.threePlugs instanceof Function) {
    	//给电器通电
        obj.threePlugs()
    }
}

socket(new Television())
//输出结果:电视机通电了
socket(new Adapter())
//输出结果:吸尘器通电了

看上方代码,我们通电的对象变成了转接头,因为转接头内部去写死了一个返回吸尘器四插头通电的调用,但是表面上我们调用的还是转接头的三接头,所以插座是可以完美调用吸尘器和电视机的

当然了有人会说,这样是挺丑陋的,但是实际上我们可以给适配器做一个适用于所有的四插头的电器的通用适配器

// 定义可以转接所有插头的适配器类
class Adapter{
	constructor(obj) {
    	this.obj= obj
  	},
    threePlugs() {
        var obj= new this.obj()
        return obj.fourPlug()
    }
}

socket(new Adapter(VacuumCleaner))
//尚未验证此种写法的正确性,但是思想就是这样的,我们可以给要适配的插头传进去,传什么插头就给什么的四插头适配成三插头

适配器的概念以及模式都非常简单,就是转接头的概念,当然了深挖肯定是有很多的使用的地方,起到神奇的效果,毕竟每个设计模式的概念都是总结出来的,十分实用的,循序渐进,多看文章,就能发现各个设计模式的神奇之处