②【結構型設計模式】配接器模式

一、寫在前面

配接器模式(Adapter)：將一個類(物件）的介面(方法或者屬性）轉化成另外一個介面，以滿足用戶需求，使類(物件）之間介面的不兼容問題通過配接器得以解決，

上述的簡介，你能想到這個模式是怎么樣的嗎？

本系列文章上次更新是一個月前了，很抱歉，最近專案太忙了，我已經加了一個月的班了，月平均工時12.1個小時，回到家的時候基本上都是23點左右了，實在太累了，

關注公眾號“筆優站長”可閱讀全部文章喲，

二、場景實體 —— JQuery

生活中的配接器

可能直接說配接器，還是有朋友會出現一臉懵逼的樣子，那就舉個簡單的例子，

生活中這種模式也很常見，你看公司的水房的兩根垂直相交的水管連接處的直角彎管了么?它就是一個配接器，它使得兩個不同方向的水管可以疏通流水，再比如我們三角插頭手機充電器對于兩項插頭是不能用的，此時我們就需要一個三項轉兩項插頭電源配接器等等，這些都是配接器，

JQuery配接器

jQuery曾經也是一個時代的王者，但是隨著單頁應用的發展，以及資料驅動的出現，直接操作dom的方式逐漸就沒落了，例如現在的Vue、React等，

那么曾經的這個王者還有值得我們學習的地方嗎？答案是肯定的，雖然目前直接操作dom的方式沒那么流行了，但是jQuery的封裝以及設計模式上，還是有值得我們去學習的地方，

但是這里并不是重點說jQuery，請看下面的例子：

假如公司里有個內部框架 A 框架

A(function(){
	A('button').on('click',function(){
		//TODO...
	});
});

這個框架和jQuery十分相似，只不過功能方法沒有jQuery多，命名方式是A，jQuery的方法是jQuery或者$，你看公司的A框架代碼書寫格式是不是與jQuery代碼書寫格式很像，所以你需要在加載完jQuery框架后寫一個配接器，將我們已有的功能適配到jQuery，比如代碼中有兩個
件，一個頁面加載事件，一個點擊事件，不過這兩個事件與jQuery中的寫法很像，所以這就不用做多少改動了，我們的配接器主要的任務是適配兩種代碼庫中不兼容的代碼，那么首其沖的就是全域物件A與jQuery了，所以你可以像下面這樣輕松實作，

window.A = A = jQuery;

做完這個，你重繪頁面看看是不是運行良好?

適配異類框架

類似于jQuery的輕量級框架要做適配就可以直接進行覆寫，那么假如兩個相似程度屬于“遠親”的這種又怎么處理呢？

舉個例子：

//定義A框架
var A = A || {};
//通過ID獲取元素
A.g = function(id){
	return document.getElementById(id)；
｝
//為元素系結事件
A.on = function(id,type,fn)(
	//如果傳遞引數是字串則以id處理，否則以元素物件處理
	var dom=typeof id ==='string'?this.g(id):id;
	//標準DOM2級添加事件方式
	if(dom.addEventListener)(
		dom.addEventListener(type,fn,false);
		//IE DOM2級添加事件方式
	}else if(dom.attachEvent){
		dom.attachEvent('on' + type,fn);
		//簡易添加事件方式
	}else{
		dom['on'+ type] = fn;
	}
}

那么要完成上面的需求我們可以這樣做，

//視窗加載完成事件
A.on(window,'load',function()(
	//按鈕點擊事件
	A.on('mybutton','click',function(){
		// do something
	})
})

那么我想引入jQuery來換原有的A庫，你知道該如何做么?

思路: 首先g方法是通過id獲取元素，所以通過$(jQuery的簡寫名稱)方法獲取jQuery物件然后通過get獲取第一個成員即可，不過on方法有些復雜，我們不能直接替換，因為jQuery和我們的A庫在通過id獲取元素時是有區別的，jQuery的id前面要加#，所以異類框架的配接器應該是這樣的吧，

A.g= function(id){
	//通過jQuery獲取jQuery物件，然后回傳第一個成員
	return.$(id).get(0);
}

A.on = function(id,type,fn){
	//如果傳遞引數是字串則以id處理，否則以元素物件處理
	var dom = typeof id ==='string'?$('#'+ id):$(id);dom.on(type,fn);
}

通過配接器我們發現如果兩種框架的‘血緣’比較相近，那么我們適配起來是比較容易的，如果‘血緣’相差甚遠我們的配接器寫起來要復雜得多，因此要記住，日后非到萬不得已情況下，盡量引入相似框架，

引數配接器

/**
 * obj.name : name
 * obj.title : title
 * obj.age : age
 * obj.color : color
 * obj.size : size
 * obj.prize : prize
 */
function doSomeThing(obj){}

上面有這樣一個方法，然而當呼叫它的時候又不知道傳遞的引數是否完整，如有一些必須引數沒有傳入，一些引數是有默認值的等等，此時我們通常的做法是用配接器來適配傳入的這個引數物件，如下所示：

function dosomeThing(obj)(
	var _adapter = {
		name:'雨夜清荷',
		title:'設計模式,
		age:24,
		color:'pink',
		size:100,
		prize:50
	}
	for (var i in _adapter){
		adapter[i] = obj[i] || adapter[i];
	}
	//或者extend(_adapter，obj)注：此時可能會多添加屬性
	// do things
}

其實這種方式很常見，很多插件對于引數配置都是這么做的，

留下兩個問題：

資料適配

？？？

服務端資料適配

？？？

這兩個和前面說的都大同小異，有思路就能解決，

三、總結

傳統設計模式中，配接器模式往往是適配兩個類介面不兼容的問題，然而在JavaScript中，配接器的應用范圍更廣，比如適配兩個代碼庫，適配前后端資料，等等，

JavaScript中的配接器的應用，更多應用在物件之間，為了使物件可用，通常我們會將物件拆分并重新包裝，這樣我們就要了解適配物件的內部結構，這也是與外觀模式的區別所在，當然配接器模式同樣解決了物件之間的耦合度，包裝的配接器代碼增加了一些資源開銷，當然這是微乎其微的，

下章劇透 ：跨域訪問的問題，該如何解決呢？

六、寫在后面

上面就是結構型設計模式中的——配接器模式的全部內容了，你學廢了嗎？

有問題請留言或者@博主,謝謝支持o(￣︶￣)o~

感謝您的閱讀,如果此文章或專案對您有幫助，請掃個二維碼點個關注吧，若可以的話再給個一鍵三連吧！

公眾號閱讀的朋友可以點一下右下角的在看和分享哦，

GitHub有開源專案,需要的小伙伴可以順手star一下！

GitHub: https://github.com/langyuxiansheng

更多資訊請關注公眾號: “筆優站長”