適配器模式 · 日常學習

## 引入在閻宏博士的《JAVA與模式》一書中開頭是這樣描述適配器（Adapter）模式的： > 適配器模式把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。用電器做例子，筆記本電腦的插頭一般都是三相的，即除了陽極、陰極外，還有一個地極。而有些地方的電源插座卻只有兩極，沒有地極。電源插座與筆記本電腦的電源插頭不匹配使得筆記本電腦無法使用。這時候一個三相到兩相的轉換器（適配器）就能解決此問題，而這正像是本模式所做的事情。 ## 定義適配器模式就是將一個類的接口，轉換成客戶期望的另一個接口。適配器讓原本接口不兼容的類可以合作無間。在適配器模式中，我們可以定義一個包裝類，包裝不兼容接口的對象，這個包裝類就是適配器，它所包裝的對象就是適配者。適配器提供給客戶需要的接口，適配器的實現就是將客戶的請求轉換成對適配者的相應的接口的引用。也就是說，當客戶調用適配器的方法時，適配器方法內部將調用適配者的方法，客戶并不是直接訪問適配者的，而是通過調用適配器方法訪問適配者。因為適配器可以使互不兼容的類能夠“合作愉快”。 ## 模式結構適配器模式充滿著良好的OO設計原則：使用對象組合，以修改的接口包裝別適配者。而且這樣做還有一個優點，被適配者的任何子類，都可以搭配適配器使用。適配器模式有三種不同的種類：類的適配器模式、對象的適配器模式和接口的適配器模式。 ### 類適配器模式類的適配器模式把適配的類的API轉換成為目標類的API。 ![](https://box.kancloud.cn/4889e302b870c3501710a9ff0ae2de36_544x252.png) 在上圖中可以看出，Adaptee類并沒有sampleOperation2()方法，而客戶端則期待這個方法。為使客戶端能夠使用Adaptee類，提供一個中間環節，即類Adapter，把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是繼承關系，這決定了這個適配器模式是類的：　　模式所涉及的角色有：　　●　　目標(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類。 ![](https://box.kancloud.cn/53f5d3a08465361fedd0cc2f6dbd7a50_574x265.png) 從上圖可以看出，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(){ //寫相關的代碼 } } ~~~ ### 接口適配器模式（缺省適配）缺省適配(Default Adapter)模式為一個接口提供缺省實現，這樣子類型可以從這個缺省實現進行擴展，而不必從原有接口進行擴展。作為適配器模式的一個特例，缺省是適配模式在JAVA語言中有著特殊的應用。 **場景**: 有時候我們抽象方法時,可能會在一個接口中抽象出多個方法,但是有些實現類并不需要該接口的全部的方法聲明,如果將全部的聲明方法全部實現的話,明顯會很浪費.所以當我們需要某一個接口中的部分方法的時候,可以使用接口的適配器模式. **做法**：在要實現的類與接口之間增加一個抽象類,由由抽象類實現接口.然后要實現的類不在實現接口,轉而繼承抽象類,這樣就可以通過重寫自己需要的方法來完成需求. 缺省適配模式是一種“平庸”化的適配器模式。 ![](https://box.kancloud.cn/2c4500dd71e2ebbf415d1fecdeb0e07a_293x319.png) **代碼實現** 和尚要做什么呢？吃齋、念經、打坐、撞鐘、習武等。如果設計一個和尚接口，給出所有的和尚都需要實現的方法，那么這個接口應當如下： ~~~ 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的具體類都可以選擇它所需要的方法實現，而不必理會其他的不需要的方法。適配器模式的用意是要改變源的接口，以便于目標接口相容。缺省適配的用意稍有不同，它是為了方便建立一個不平庸的適配器類而提供的一種平庸實現。　　在任何時候，如果不準備實現一個接口的所有方法時，就可以使用“缺省適配模式”制造一個抽象類，給出所有方法的平庸的具體實現。這樣，從這個抽象類再繼承下去的子類就不必實現所有的方法了。 ### 類適配器和對象適配器的權衡一、**類適配器**使用對象繼承的方式，是靜態的定義方式；而對**象適配器**使用對象組合的方式，是動態組合的方式。二、對于**類適配器**，由于適配器直接繼承了Adaptee，使得適配器不能和Adaptee的子類一起工作，因為繼承是靜態的關系，當適配器繼承了Adaptee后，就不可能再去處理 Adaptee的子類了。對于**對象適配器**，一個適配器可以把多種不同的源適配到同一個目標。換言之，同一個適配器可以把源類和它的子類都適配到目標接口。因為對象適配器采用的是對象組合的關系，只要對象類型正確，是不是子類都無所謂。三、對于**類適配器**，適配器可以重定義Adaptee的部分行為，相當于子類覆蓋父類的部分實現方法。對于**對象適配器**，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類來實現重定義，然后讓適配器組合子類。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可同時適用于所有的源。對于**類適配器**，僅僅引入了一個對象，并不需要額外的引用來間接得到Adaptee。對于**對象適配器**，需要額外的引用來間接得到Adaptee。 ## 優點　　* 更好的復用性。系統需要使用現有的類，而此類的接口不符合系統的需要。那么通過適配器模式就可以讓這些功能得到更好的復用。 * 　　更好的擴展性。在實現適配器功能的時候，可以調用自己開發的功能，從而自然地擴展系統的功能。 ## 缺點　　過多的使用適配器，會讓系統非常零亂，不易整體進行把握。比如，明明看到調用的是A接口，其實內部被適配成了B接口的實現，一個系統如果太多出現這種情況，無異于一場災難。因此如果不是很有必要，可以不使用適配器，而是直接對系統進行重構。 ## 應用場景 * 類的適配器模式 : 系統需要使用現有的類,而此類的接口不符合系統的需要.這樣就需要編寫一個新的接口,創建一個適配器角色類,繼承源角色類,實現新的接口即可. * 對象的適配器模式 : 當希望將一個對象轉換成滿足另一個新接口的對象時,可以創建一個Adapter類,持有原類的一個實例,在Adapter類的方法中調用原類的方法即可. * 接口的適配器模式 : 不希望實現一個接口中的所有方法時,可以創建一個抽象類AdpterSub,實現所有方法,使用接口中的某些方法時,只需要繼承抽象類AdpterSub中那些方法,并重寫就可以。 ## 總結 1、當我們需要使用的一個現有的類，但是他的接口并不符合我們的需求時，我們可以使用適配器模式。 2、適配器模式分為類適配器和對象適配器，其中類適配器需要用到多重繼承。**建議盡量使用對象適配器的實現方式**，多用合成/聚合、少用繼承。當然，具體問題具體分析，根據需要來選用實現方式，最適合的才是最好的。