適配器模式可以根據(jù)需求轉(zhuǎn)換(或調(diào)整)一個接口,創(chuàng)建含有您所需接口的另一個對象,并將它連接到您想改變接口的對象,從而完成這種轉(zhuǎn)換,下面就來詳解JavaScript實現(xiàn)設(shè)計模式中的適配器模式的方法
有的時候在開發(fā)過程中,我們會發(fā)現(xiàn),客戶端需要的接口和提供的接口發(fā)生不兼容的問題。由于特殊的原因我們無法修改客戶端接口。在這種情況下,我們需要適配現(xiàn)有接口和不兼容的類,這就要提到適配器模式。通過適配器,我們可以在不用修改舊代碼的情況下也能使用它們,這就是適配器的能力。
適配模式可用來在現(xiàn)有接口和不兼容的類之間進(jìn)行適配,使用這種模式的對象又叫包裝器(wrapper),因為它們是在用一個新的接口包裝另一個對象。
從表面上看,適配器模式很像外觀模式。它們都要對別的對象進(jìn)行包裝并改變其呈現(xiàn)的接口。二者的差別在于它們?nèi)绾胃淖兘涌?。外觀元素展現(xiàn)的是一個簡化的接口,它并不提供額外的選擇,而且有時為了方便完成常見任務(wù)它還會做出一些假定。而適配器則要把一個接口轉(zhuǎn)換為另一個接口,它并不會濾除某些能力,也不會簡化接口。如果客戶系統(tǒng)API不可用,就需要用到適配器。
基本理論
適配器模式:將一個接口轉(zhuǎn)換成客戶端需要的接口而不需要去修改客戶端代碼,使得不兼容的代碼可以一起工作。
適配器主要有3個角色組成:
(1)客戶端:調(diào)用接口的類
(2)適配器:用來連接客戶端接口和提供服務(wù)的接口的類
(3)適配者:提供服務(wù),但是卻與客戶端接口需求不兼容服務(wù)類。
適配器模式的實現(xiàn)
1.最簡單的適配器
適配器模式?jīng)]有想象中的那么復(fù)雜,舉個最簡單的例子。
客戶端調(diào)用一個方法進(jìn)行加法計算:
var result = add(1,2);
但是我們沒有提供add這個方法,提供了同樣類似功能的sum方法:
function sum(v1,v2){
return v1 + v2;
}
為了避免修改客戶端和服務(wù)端,我們增加一個包裝函數(shù):
function add (v1,v2){
reutrn sum(v1,v2);
}
這就是一個最簡單的適配器模式,我們在兩個不兼容的接口之間添加一個包裝方法,用這個方法來連接二者使其共同工作。
2.實際應(yīng)用
隨著前端框架的發(fā)展,越來越多的開發(fā)者開始使用MVVM框架進(jìn)行開發(fā),只需要操作數(shù)據(jù)而不需要操作DOM元素,jQuery的作用越來越少。而很多項目中還是引用著jQuery庫作用工具類,因為我們要利用jQuery提供的ajax去服務(wù)器請求數(shù)據(jù)。如果jQuery在項目中的作用僅僅是作為ajax工具庫的話,有點殺雞焉用牛刀的感覺,造成資源浪費。這個時候我們完全可以封裝一個自己的ajax庫。
假設(shè)我們封裝的ajax就通過一個函數(shù)進(jìn)行使用:
ajax({
url:'/getData',
type:'Post',
dataType:'json',
data:{
id:"123"
}
})
.done(function(){})
除了調(diào)用接口ajax與jQuery的$.ajax的不同,其他完全一樣。
項目中請求ajax的地方必然很多,我們替換jQuery的時候不可能一個一個去修改$.ajax,那怎么辦呢,這個時候,我們就可以增加一個適配器:
var $ = {
ajax:function (options){
return ajax(options);
}
}
這樣就能兼容舊代碼和新接口,避免對已有的代碼的修改。
總結(jié)
適配器模式的原理很簡單,就是新增一個包裝類,對新的接口進(jìn)行包裝以適應(yīng)舊代碼的調(diào)用,避免修改接口和調(diào)用代碼。
適用場景:存在較多代碼調(diào)用舊接口,為了避免修改舊代碼和更換新接口,不影響現(xiàn)有實現(xiàn)方式的應(yīng)用場景。
1.適配器模式的適用場合:
適配器適用于客戶系統(tǒng)期待的接口與現(xiàn)有API提供的接口不兼容這種場合。適配器所適配的兩個方法執(zhí)行的應(yīng)該是類似的任務(wù),否則的話就解決不了問題。就像橋接元素和外觀元素一樣,通過創(chuàng)建適配器,可以把抽象與其實現(xiàn)隔離開來,以便二者獨立變化。
2.適配器模式之利:
用一個新的接口對現(xiàn)有類的接口進(jìn)行包裝,這樣客戶程序就能使用這個并非為其量身打造的類而又無需為此大動手術(shù)。
3.設(shè)配器模式之弊:
有人認(rèn)為適配器是一種不必要的開銷,完全可以通過重寫現(xiàn)有代碼避免。此外適配器模式也會引入一批需要支持的新工具。如果現(xiàn)有API還未定形,或者新接口還未定形,那么適配器可能不會一直管用。
在涉及大型系統(tǒng)和遺留框架的情況下,它的優(yōu)點往往比缺點更突出。