JavaScript设计模式 Item9 --适配器模式Adapter
适配器模式(转换器面模式)，通常是为要使用的接口,不符本应用或本系统使用,而需引入的中间适配层类或对象的情况。
适配器模式的作用是解决两个软件实体间的接口不兼容的问题。
一、定义
适配器模式（Adapter）是将一个类（对象）的接口（方法或属性）转化成客户希望的另外一个接口（方法或属性），适配器模式使得原本由于接口不兼容而不能一起工作的那些类（对象）能够一些工作。
速成包装器（wrapper）。
适配器的别名是包装器（wrapper），这是一个相对简单的模式。在程序开发中有很多这种场景：当我们试图调用模块或者对象的某个接口时，却发现这个接口的格式并不符合眼下的需求。这时候有两种解决的方法。第一种是改动原来的接口实现，但假设原来的模块非常复杂，或者我们拿到的模块是一段别人编写的经过压缩的代码，改动原接口就显得不太现实了。
第二种办法是创建一个适配器，将原接口转换为客户希望的还有一个接口。客户仅仅须要和适配器打交道。
二、现实生活中的适配器
场景: 就好比我们买了台手机，买回来后发现。充电线插头是三插头，但家里。仅仅有两插头的口的插座，怎么办？为了方便，也有为能在不论什么地方都能充上电。就得去买个通用充电适配器; 这样手机才干在自己家里充上电；不然仅仅能放着，或跑到有这个插头的地方充电；
三、适配器模式
假设现有的接口已经能够正常工作，那我们就永远不会用上适配器模式。
适配器模式是一种“亡羊补牢”的模式。没有人会在程序的设计之初就使用它。
由于没有人能够全然预料到未来的事情，或许如今好好工作的接口，未来的某天却不再适用于新系统，那么我们能够用适配器模式把旧接口包装成一个新的接口。使它继续保持生命力。比方在JSON 格式流行之前。非常多cgi 返回的都是XML 格式的数据。假设今天仍然想继续使用这些接口，显然我们能够创造一个。
XML-JSON 的适配器。
3.1 參数适配器
有时候。我们在定义函数的时候须要传递N多个參数，比如：
function doSomething(name,title, age,color,size,prize){}
我们要记住这些參数的顺序是非常难的，那怎么办呢？我们经常会以一个參数对象的形式传递，例如以下：
/* params.name:name
params.title:title
params.age:age
params.color:color
params.size:size
params.prize:prize*/
function doSomething(params){}
然而在实际调用的过程中，并不知道传递的參数是否完整。如一些必须的參数没有传入。一些參数有初始值。
此时我么你就能够通过适配器来适配这些參数的要求，例如以下：
function doSomething(params){
var _adapter={
name:"适配器",
title:"设计模式",
age:24,
color:"pink",
size:240,
prize:50
};
for(var i in _adapter){
_adapter[i] = params[i] || _adapter[i];
}
//或者extend(_adapter,params);这有可能会添加属性
}
四、数据适配器
比方在一些插件的开发中，存在着非常多对数据的适配，比方说以下是一个数组
var arr=[“javascript”,”book”,”前端编程利器”,”3月14日”];
我们发现数组中的数据代表不同的意义，这种数据在语义上非常不友好。我们可能会要求把它转化为对象的形式：
var obj={
name:"",
type:"",
title:"",
time:""
}
依照需求，我们能够定义这么一个数据适配器
function arrToObjAdapter(){
return{
name:arr[0],
type:arr[1],
title:arr[2],
date:arr[3]
};
}
var adapterData = arrToObjAdapter(arr);
console.log(adapterData);
这给我们灵活使用数据提供了新思路。
五、前后台数据适配
当我们向googleMap 和baiduMap 都发出“显示”请求时，googleMap和baiduMap 分别以各自的方式在页面中展现了地图：
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 ); // 输出：開始渲染百度地图
这段程序得以顺利执行的关键是googleMap 和baiduMap 提供了一致的show 方法，但第三方的接口方法并不在我们自己的控制范围之内。假如baiduMap 提供的显示地图的方法不叫show 而叫display 呢？
baiduMap 这个对象来源于第三方，正常情况下我们都不应该去改动它。此时我们能够通过添加baiduMapAdapter 来解决这个问题：
var googleMap = {
show: function(){
console.log( '開始渲染谷歌地图' );
}
};
var baiduMap = {
display: function(){
console.log( '開始渲染百度地图' );
}
};
var baiduMapAdapter = {
show: function(){
return baiduMap.display();
}
};
renderMap( googleMap ); // 输出：開始渲染谷歌地图
renderMap( baiduMapAdapter ); // 输出：開始渲染百度地图
再来看看另外一个样例。假设我们正在编写一个渲染广东省地图的页面。眼下从第三方资源里获得了广东省的全部城市以及它们所相应的ID，而且成功地渲染到页面中：
var getGuangdongCity = function(){
var guangdongCity = [
{
name: 'shenzhen',
id: 11,
}, {
name: 'guangzhou',
id: 12,
}];
return guangdongCity;
};
var render = function( fn ){
console.log( '開始渲染广东省地图' );
document.write( JSON.stringify( fn() ) );
};
render( getGuangdongCity );
利用这些数据，我们编写完毕了整个页面。而且在线上稳定地执行了一段时间。但后来发现这些数据不太可靠，里面还缺少非常多城市。于是我们又在网上找到了另外一些数据资源，这次的数据更加全面。但遗憾的是，数据结构和正执行在项目中的并不一致。
新的数据结构例如以下：
var guangdongCity = {
shenzhen: 11,
guangzhou: 12,
zhuhai: 13
};
除了大动干戈地改写渲染页面的前端代码之外，第二种更轻便的解决方案就是新增一个数据格式转换的适配器：
var addressAdapter = function( oldAddressfn ){
var address = guangdongCity,
oldAddress = oldAddressfn();
for ( var i = 0, c; c = oldAddress[ i++ ]; ){
address[ c.name ] = c.id;
}
return address;
};
render( addressAdapter( getGuangdongCity ) );
那么接下来须要做的。就是把代码中调用getGuangdongCity 的地方，用经过addressAdapter适配器转换之后的新函数来取代。
六、应用场景
那合适使用适配器模式好呢？假设有以下情况出现时，建议使用：
- 使用一个已经存在的对象，但其方法或属性接口不符合你的要求；
- 你想创建一个可复用的对象，该对象能够与其他不相关的对象或不可见对象（即接口方法或属性不兼容的对象）协同工作；
- 想使用已经存在的对象，可是不能对每个都进行原型继承以匹配它的接口。
对象适配器能够适配它的父对象接口方法或属性。
有一些模式跟适配器模式的
结构非常类似，比方装饰者模式、代理模式和外观模式。这几种模式都属于“包
装模式”。都是由一个对象来包装还有一个对象。差别它们的关键仍然是模式的意图。
适配器模式主要用来解决两个已有接口之间不匹配的问题，它不考虑这些接口是如何实现的，也不考虑它们将来可能会如何演化。适配器模式不须要改变已有的接口。就能够使它们协同作用。
装饰者模式和代理模式也不会改变原有对象的接口，但装饰者模式的作用是为了给对象添加功能。
装饰者模式经常形成一条长的装饰链，而适配器模式通常仅仅包装一次。代理模式是为了控制对对象的訪问，通常也仅仅包装一次。
外观模式的作用倒是和适配器比較类似。有人把外观模式看成一组对象的适配器，但外观模式最显著的特点是定义了一个新的接口。
