适配器模式 —情人节哦-情人节 🐣🌹
先讲一下适配器，我们浏览器搜索可以知道该词的具体含义。
适配器是一个接口转换器;
它可以是一个独立的硬件接口设备，允许硬件或电子接口与其它硬件或电子接口相连;
也可以是信息接口。比如：电源适配器、三角架基座转接部件、USB与串口的转接设备等;
在计算机硬件中，可以理解为两种设备的连接处，为了实现某种连通目的而实现的。
1. javascript的设计模式-适配器模式也是借鉴此理念模式，基于代码开发层面的总结。
用一天的时间，抽空看完一种设计模式，或者两天，还是有收获的，我们需要耐心，这个从长远来说，不算慢的。
适配器可以被添加到现有代码中以协调两个不同的接口。
如果现有代码的接口能很好地满足需要，那就可能没有必要使用适配器。但要是现有接口对于手头的工作来说不够直观或实用，那
么可以使用适配器来提供一个更简洁或更丰富 （option-rich）的接口。
适配器可被实现为不兼容的方法调用之间的一个代码薄层。
2. 一个比较基本的适配案例如下
如果你有一个具有3个字符串参数的函数，但客户系统拥有的却是一个包含三个字符串元素的数组，此时就可以用一个适配器来 衔接二者。
假设你有一个对象，还有一个以三个字符串为参数的两数,如下：
1
2
3
4
5
6
7
8
var clientobiect ={
string1:"foo",
string2: 'bar',
string3: 'baz',
};
function interfaceMethod(str1, str2, str3) {
// ...
}
为了把clientobject作为参数传递给 interfacevethod，需要用到适配器。我们可以这样创建一个适配器：
1
2
3
4
5
function clientToInterfaceAdapter(o){
interfaceMethod(o.string1, o.string2, o.string3);
}
// 现在就可以把整个对象传递给这个函数：
clientToInterfaceAdapter(clientObject);
这个可能我们日常开发中已经基本很好的用到了，从 js设计模式的内容来看，后面列举了三五个不用的方法，
以捍卫该模式，然后列举出了使用适配器的场景，以及利弊。
-
2.2另外一个实际应用中比较常见的案例如下：
假如一个项目需要用到另外一个项目的 代码方法，比如我们要使用到api相关的。但是他的好多变量需要改，这时候，
我们最好的做法是 适配这个变量，而不是替换这个变量。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
let baseUrl = {
devUrl:''
}
export const obj = {
a:baseUrl.devUrl+'/xx/xx',
b:baseUrl.devUrl+'/xx/xx',
}
// 如上这段代码，我们要替换 a,b元素中的baseUrl.devUrl变量改动会比较多的，
// 我们不如设置 给 baseUrl.devUrl复值待对接适配的变量值更好
import newDevelopmentUrl from 'xx'
let baseUrl = {
devUrl:newDevelopmentUrl
}
// ....
// 这样我们就不需要替换obj对象中各个元素的baseUrl.devUrl 字段了
3. 适配器模式之利
1
适配器有助于避免大规模改写现有客户代码。其工作机制是：用一个新的接口对现有类的接口进行包装，这样容户程序就能使用这个并非为其量身打造的类而又毋需为此大动手术。
4. 适配器模式之弊
1
2
3
4
可能有些工程师不想使用适配器，其原因主要在于他们实际上需要彻底重写代码。
有人认为适配器是一种不必要的开销，完全可以通过重写现有代码避免。
此外适配器模式也会引入一批需要支持的新工具。如果现有API还未定形，或者新接口还末定形（这更有可能），
那么适配器可能不会一直管用。在设计键盘的硬件工程师创造PS2-t0-USB适配器这个案例中，成千上万的键盘上面的PS2插头不会再有什么变化，而USB接口则成了新的标准，所以这种适配器才有意义。但是在软件开发这一行中，情况并非总是如此。
我的读后感；
1
2
3
适配器方式已经在代码开发中不经意的有在使用中，我们可能已经在潜移默化中，
在考虑代码结构，可用性的时候，已经不经意的使用了，这里的理念算是一次特意的提醒,提亮技术专业度。
平常适配器不需要刻意去使用，在某些场景遇到了综合考虑之后顺其自然的适当使用即可。
