在閻宏博士的《JAVA與模式》一書中開頭是這樣描述適配器(Adapter)模式的:程序員
適配器模式把一個類的接口變換成客戶端所期待的另外一種接口,從而使本來因接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。編程
用電器作例子,筆記本電腦的插頭通常都是三相的,即除了陽極、陰極外,還有一個地極。而有些地方的電源插座卻只有兩極,沒有地極。電源插座與筆記本電腦的電源插頭不匹配使得筆記本電腦沒法使用。這時候一個三相到兩相的轉換器(適配器)就能解決此問題,而這正像是本模式所作的事情。app
適配器模式有類的適配器模式和對象的適配器模式兩種不一樣的形式。編輯器
類的適配器模式把適配的類的API轉換成爲目標類的API。ide
在上圖中能夠看出,Adaptee類並無sampleOperation2()方法,而客戶端則期待這個方法。爲使客戶端可以使用Adaptee類,提供一箇中間環節,即類Adapter,把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是繼承關係,這決定了這個適配器模式是類的:this
模式所涉及的角色有:spa
● 目標(Target)角色:這就是所期待獲得的接口。注意:因爲這裏討論的是類適配器模式,所以目標不能夠是類。設計
● 源(Adapee)角色:如今須要適配的接口。對象
● 適配器(Adaper)角色:適配器類是本模式的核心。適配器把源接口轉換成目標接口。顯然,這一角色不能夠是接口,而必須是具體類。繼承
public interface Target { /** * 這是源類Adaptee也有的方法 */ public void sampleOperation1(); /** * 這是源類Adapteee沒有的方法 */ public void sampleOperation2(); }
上面給出的是目標角色的源代碼,這個角色是以一個JAVA接口的形式實現的。能夠看出,這個接口聲明瞭兩個方法:sampleOperation1()和sampleOperation2()。而源角色Adaptee是一個具體類,它有一個sampleOperation1()方法,可是沒有sampleOperation2()方法。
public class Adaptee { public void sampleOperation1(){} }
適配器角色Adapter擴展了Adaptee,同時又實現了目標(Target)接口。因爲Adaptee沒有提供sampleOperation2()方法,而目標接口又要求這個方法,所以適配器角色Adapter實現了這個方法。
public class Adapter extends Adaptee implements Target { /** * 因爲源類Adaptee沒有方法sampleOperation2() * 所以適配器補充上這個方法 */ @Override public void sampleOperation2() { //寫相關的代碼 } }
與類的適配器模式同樣,對象的適配器模式把被適配的類的API轉換成爲目標類的API,與類的適配器模式不一樣的是,對象的適配器模式不是使用繼承關係鏈接到Adaptee類,而是使用委派關係鏈接到Adaptee類。
從上圖能夠看出,Adaptee類並無sampleOperation2()方法,而客戶端則期待這個方法。爲使客戶端可以使用Adaptee類,須要提供一個包裝(Wrapper)類Adapter。這個包裝類包裝了一個Adaptee的實例,從而此包裝類可以把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是委派關係,這決定了適配器模式是對象的。
public interface Target { /** * 這是源類Adaptee也有的方法 */ public void sampleOperation1(); /** * 這是源類Adapteee沒有的方法 */ public void sampleOperation2(); }
public class Adaptee { public void sampleOperation1(){} }
public class Adapter { private Adaptee adaptee; public Adapter(Adaptee adaptee){ this.adaptee = adaptee; } /** * 源類Adaptee有方法sampleOperation1 * 所以適配器類直接委派便可 */ public void sampleOperation1(){ this.adaptee.sampleOperation1(); } /** * 源類Adaptee沒有方法sampleOperation2 * 所以由適配器類須要補充此方法 */ public void sampleOperation2(){ //寫相關的代碼 } }
● 類適配器使用對象繼承的方式,是靜態的定義方式;而對象適配器使用對象組合的方式,是動態組合的方式。
● 對於類適配器,因爲適配器直接繼承了Adaptee,使得適配器不能和Adaptee的子類一塊兒工做,由於繼承是靜態的關係,當適配器繼承了Adaptee後,就不可能再去處理 Adaptee的子類了。
對於對象適配器,一個適配器能夠把多種不一樣的源適配到同一個目標。換言之,同一個適配器能夠把源類和它的子類都適配到目標接口。由於對象適配器採用的是對象組合的關係,只要對象類型正確,是否是子類都無所謂。
● 對於類適配器,適配器能夠重定義Adaptee的部分行爲,至關於子類覆蓋父類的部分實現方法。
對於對象適配器,要重定義Adaptee的行爲比較困難,這種狀況下,須要定義Adaptee的子類來實現重定義,而後讓適配器組合子類。雖然重定義Adaptee的行爲比較困難,可是想要增長一些新的行爲則方便的很,並且新增長的行爲可同時適用於全部的源。
● 對於類適配器,僅僅引入了一個對象,並不須要額外的引用來間接獲得Adaptee。
對於對象適配器,須要額外的引用來間接獲得Adaptee。
建議儘可能使用對象適配器的實現方式,多用合成/聚合、少用繼承。固然,具體問題具體分析,根據須要來選用實現方式,最適合的纔是最好的。
系統須要使用現有的類,而此類的接口不符合系統的須要。那麼經過適配器模式就可讓這些功能獲得更好的複用。
在實現適配器功能的時候,能夠調用本身開發的功能,從而天然地擴展系統的功能。
過多的使用適配器,會讓系統很是零亂,不易總體進行把握。好比,明明看到調用的是A接口,其實內部被適配成了B接口的實現,一個系統若是太多出現這種狀況,無異於一場災難。所以若是不是頗有必要,能夠不使用適配器,而是直接對系統進行重構。
缺省適配(Default Adapter)模式爲一個接口提供缺省實現,這樣子類型能夠從這個缺省實現進行擴展,而沒必要從原有接口進行擴展。做爲適配器模式的一個特例,缺省是適配模式在JAVA語言中有着特殊的應用。
和尚要作什麼呢?吃齋、唸經、打坐、撞鐘、習武等。若是設計一個和尚接口,給出全部的和尚都須要實現的方法,那麼這個接口應當以下:
public interface 和尚 { public void 吃齋(); public void 唸經(); public void 打坐(); public void 撞鐘(); public void 習武(); public String getName(); }
顯然,全部的和尚類都應當實現接口所定義的所有方法,否則就根本通不過JAVA語言編輯器。像下面的魯智深類就不行。
public class 魯智深 implements 和尚{ public void 習武(){ 拳打鎮關西; 大鬧五臺山; 大鬧桃花村; 火燒瓦官寺; 倒拔垂楊柳; } public String getName(){ return "魯智深"; } }
因爲魯智深只實現了getName()和習武()方法,而沒有實現任何其餘的方法。所以,它根本就通不過Java語言編譯器。魯智深類只有實現和尚接口的全部的方法才能夠經過Java語言編譯器,可是這樣一來魯智深就再也不是魯智深了。以史爲鑑,能夠知天下。研究一下幾百年前魯智深是怎麼剃度成和尚的,會對Java編程有很大的啓發。不錯,當初魯達剃度,衆僧說:「此人形容醜惡、相貌兇頑,不可剃度他",可是長老卻說:」此人上應天星、心地剛直。雖然時下兇頑,命中駁雜,久後卻得清淨。證果非凡,汝等皆不及他。」
原來如此!看來只要這裏也應上一個天星的話,問題就解決了!使用面向對象的語言來講,「應」者,實現也;「天星」者,抽象類也。
public abstract class 天星 implements 和尚 { public void 吃齋(){} public void 唸經(){} public void 打坐(){} public void 撞鐘(){} public void 習武(){} public String getName(){ return null; } }
魯智深類繼承抽象類「天星」
public class 魯智深 extends 天星{ public void 習武(){ 拳打鎮關西; 大鬧五臺山; 大鬧桃花村; 火燒瓦官寺; 倒拔垂楊柳; } public String getName(){ return "魯智深"; } }
這個抽象的天星類即是一個適配器類,魯智深實際上藉助於適配器模式達到了剃度的目的。此適配器類實現了和尚接口所要求的全部方法。可是與一般的適配器模式不一樣的是,此適配器類給出的全部的方法的實現都是「平庸」的。這種「平庸化」的適配器模式稱做缺省適配模式。
在不少狀況下,必須讓一個具體類實現某一個接口,可是這個類又用不到接口所規定的全部的方法。一般的處理方法是,這個具體類要實現全部的方法,那些有用的方法要有實現,那些沒有用的方法也要有空的、平庸的實現。
這些空的方法是一種浪費,有時也是一種混亂。除非看過這些空方法的代碼,程序員可能會覺得這些方法不是空的。即使他知道其中有一些方法是空的,也不必定知道哪些方法是空的,哪些方法不是空的,除非看過這些方法的源代碼或是文檔。
缺省適配模式能夠很好的處理這一狀況。能夠設計一個抽象的適配器類實現接口,此抽象類要給接口所要求的每一種方法都提供一個空的方法。就像幫助了魯智深的「上應天星」同樣,此抽象類可使它的具體子類免於被迫實現空的方法。
缺省適配模式是一種「平庸」化的適配器模式。
public interface AbstractService { public void serviceOperation1(); public int serviceOperation2(); public String serviceOperation3(); }
public class ServiceAdapter implements AbstractService{ @Override public void serviceOperation1() { } @Override public int serviceOperation2() { return 0; } @Override public String serviceOperation3() { return null; } }
能夠看到,接口AbstractService要求定義三個方法,分別是serviceOperation1()、serviceOperation2()、serviceOperation3();而抽象適配器類ServiceAdapter則爲這三種方法都提供了平庸的實現。所以,任何繼承自抽象類ServiceAdapter的具體類均可以選擇它所須要的方法實現,而沒必要理會其餘的不須要的方法。
適配器模式的用意是要改變源的接口,以便於目標接口相容。缺省適配的用意稍有不一樣,它是爲了方便創建一個不平庸的適配器類而提供的一種平庸實現。
在任什麼時候候,若是不許備實現一個接口的全部方法時,就可使用「缺省適配模式」製造一個抽象類,給出全部方法的平庸的具體實現。這樣,從這個抽象類再繼承下去的子類就沒必要實現全部的方法了。