一看就懂的適配器設(shè)計模式

1 簡介

一般客戶端通過目標類的接口訪問它所提供的服務(wù)。有時，現(xiàn)有類可以滿足客戶端類的需要，但所提供接口不一定是客戶端所期望的，可能因為現(xiàn)有類中方法名與目標類中定義的方法名不一致。

這時，現(xiàn)有接口需要轉(zhuǎn)化為客戶端的期望接口，保證復(fù)用現(xiàn)有類。若不進行這樣轉(zhuǎn)化，客戶端就不能利用現(xiàn)有類所提供功能，適配器模式就可以完成這樣的轉(zhuǎn)化。

在適配器模式中可以定義一個包裝類，包裝不兼容接口的對象

• ??包裝類 適配器(Adapter)

• ??所包裝的對象 適配者(Adaptee)，即被適配的類

適配器提供客戶類需要的接口。適配器的實現(xiàn)就是把客戶端的請求轉(zhuǎn)化為對適配者的相應(yīng)接口的調(diào)用。即當客戶類調(diào)用適配器方法時，在適配器類的內(nèi)部將調(diào)用適配者類的方法，而該過程對客戶類透明，客戶類并不直接訪問適配者類。因此，適配器可以使由于接口不兼容而不能交互的類可以一起協(xié)作。

Sun公司在1996年公開了Java語言的數(shù)據(jù)庫連接工具JDBC，JDBC使得Java語言程序能夠與數(shù)據(jù)庫連接，并使用SQL語言來查詢和操作數(shù)據(jù)。JDBC給出一個客戶端通用的抽象接口，每一個具體數(shù)據(jù)庫引擎（如SQL Server、Oracle、MySQL等）的JDBC驅(qū)動軟件都是一個介于JDBC接口和數(shù)據(jù)庫引擎接口之間的適配器軟件。抽象的JDBC接口和各個數(shù)據(jù)庫引擎API之間都需要相應(yīng)的適配器軟件，這就是為各個不同數(shù)據(jù)庫引擎準備的驅(qū)動程序。

定義

Adapter Design Pattern，將一個接口轉(zhuǎn)換成客戶端希望的另一個接口，使接口不兼容的那些類可以一起工作，其別名為包裝器。既可以作為類結(jié)構(gòu)型模式，也可以作為對象結(jié)構(gòu)型模式。

就是用來做適配，將不兼容的接口轉(zhuǎn)為可兼容，讓原本由于接口不兼容而不能協(xié)作的類能協(xié)作。如各種手機線轉(zhuǎn)接頭充當適配器，把兩種不兼容接口，通過轉(zhuǎn)接便可協(xié)作。

角色

• ? Target：目標抽象類

• ? Adapter：適配器類

• ? Adaptee：適配者類

• ? Client：客戶類

2 實現(xiàn)方式

2.1 類適配器

基于繼承。

//?要轉(zhuǎn)化成的接口定義
public?interface?ITarget?{
??void?f1();
??void?f2();
??void?fc();
}

//?一組不兼容ITarget接口定義的接口
public?class?Adaptee?{
??public?void?fa()?{?//...?}
??public?void?fb()?{?//...?}
??public?void?fc()?{?//...?}
}

//?將Adaptee轉(zhuǎn)化成一組符合ITarget接口定義的接口?
public?class?Adaptor?extends?Adaptee?implements?ITarget?{
??public?void?f1()?{
????super.fa();
??}
??
??public?void?f2()?{
????//...重新實現(xiàn)f2()...
??}
??
??//?這里fc()不需要實現(xiàn)，直接繼承自Adaptee，這是跟對象適配器最大的不同點
}

2.2 對象適配器

使用組合關(guān)系來實現(xiàn)。

//?對象適配器：基于組合
public?interface?ITarget?{
??void?f1();
??void?f2();
??void?fc();
}

public?class?Adaptee?{
??public?void?fa()?{?//...?}
??public?void?fb()?{?//...?}
??public?void?fc()?{?//...?}
}

public?class?Adaptor?implements?ITarget?{
??private?Adaptee?adaptee;
??
??public?Adaptor(Adaptee?adaptee)?{
????this.adaptee?=?adaptee;
??}
??
??public?void?f1()?{
????adaptee.fa();?//委托給Adaptee
??}
??
??public?void?f2()?{
????//...重新實現(xiàn)f2()...
??}
??
??public?void?fc()?{
????adaptee.fc();
??}
}

如何選型？判斷標準：

• ??Adaptee接口不多，則兩種皆可

• ??Adaptee接口很多&&Adaptee和ITarget接口定義大部分相同，推薦類適配器，因為Adaptor復(fù)用父類Adaptee接口，比起對象適配器，Adaptor代碼量更少

• ??Adaptee接口很多&&且Adaptee和ITarget接口定義大不相同，推薦對象適配器，因為組合相比繼承更靈活

3 適用場景

適配器模式可看作一種“補償模式”，補救設(shè)計缺陷。應(yīng)用這種模式算是“無奈之舉”。設(shè)計初期就規(guī)避接口不兼容問題的話，那這種模式就無需存在了。

適配器模式的應(yīng)用場景是“接口不兼容”，那么問題就是何時接口會不兼容？

3.1 封裝缺陷接口

假設(shè)依賴的外部系統(tǒng)在接口設(shè)計方面有缺陷（如包含大量static方法），引入后會影響自身代碼的可測試性。為隔離設(shè)計缺陷，對外部系統(tǒng)提供的接口進行二次封裝。

//?該類來自外部SDK，無權(quán)修改其代碼
public?class?CD?{
??//?...
??public?static?void?staticFunction1()?{?//...?}
??
??public?void?uglyNamingFunction2()?{?//...?}

??public?void?tooManyParamsFunction3(int?paramA,?int?paramB,?...)?{?
????//...?
??}
??
???public?void?lowPerformanceFunction4()?{?//...?}
}

//?適配器模式重構(gòu)
public?class?ITarget?{
??
??void?function1();
??
??void?function2();
??
??void?fucntion3(ParamsWrapperDefinition?paramsWrapper);
??
??void?function4();
??//...
}
//?適配器類的命名不一定非帶Adaptor
public?class?CDAdaptor?extends?CD?implements?ITarget?{
??//...
??public?void?function1()?{
?????super.staticFunction1();
??}
??
??public?void?function2()?{
????super.uglyNamingFucntion2();
??}
??
??public?void?function3(ParamsWrapperDefinition?paramsWrapper)?{
?????super.tooManyParamsFunction3(paramsWrapper.getParamA(),?...);
??}
??
??public?void?function4()?{
????//...reimplement?it...
??}
}

3.2 統(tǒng)一多個類的接口設(shè)計

某功能的實現(xiàn)依賴多個外部系統(tǒng)（或類）。通過該模式，將它們的接口適配為統(tǒng)一的接口定義，然后就能使用多態(tài)復(fù)用代碼。

假如系統(tǒng)要對用戶輸入的文本內(nèi)容做敏感詞過濾，為提高過濾的召回率，引入第三方敏感詞過濾系統(tǒng)，依次對用戶輸入內(nèi)容過濾。但每個系統(tǒng)提供的過濾接口都不同，即無法使用統(tǒng)一邏輯調(diào)用各系統(tǒng)。這時就能使用適配器模式，將所有系統(tǒng)的接口適配為統(tǒng)一接口定義：

public?class?ASensitiveWordsFilter?{?//?A敏感詞過濾系統(tǒng)提供的接口
??//text是原始文本，函數(shù)輸出用***替換敏感詞之后的文本
??public?String?filterSexyWords(String?text)?{
????//?...
??}
??
??public?String?filterPoliticalWords(String?text)?{
????//?...
??}?
}

public?class?BSensitiveWordsFilter??{?//?B敏感詞過濾系統(tǒng)提供的接口
??public?String?filter(String?text)?{
????//...
??}
}

public?class?CSensitiveWordsFilter?{?//?C敏感詞過濾系統(tǒng)提供的接口
??public?String?filter(String?text,?String?mask)?{
????//...
??}
}

//?未使用適配器模式之前的代碼：代碼的可測試性、擴展性不好
public?class?RiskManagement?{
??private?ASensitiveWordsFilter?aFilter?=?new?ASensitiveWordsFilter();
??private?BSensitiveWordsFilter?bFilter?=?new?BSensitiveWordsFilter();
??private?CSensitiveWordsFilter?cFilter?=?new?CSensitiveWordsFilter();
??
??public?String?filterSensitiveWords(String?text)?{
????String?maskedText?=?aFilter.filterSexyWords(text);
????maskedText?=?aFilter.filterPoliticalWords(maskedText);
????maskedText?=?bFilter.filter(maskedText);
????maskedText?=?cFilter.filter(maskedText,?"***");
????return?maskedText;
??}
}

//?使用適配器模式進行改造
public?interface?ISensitiveWordsFilter?{?//?統(tǒng)一接口定義
??String?filter(String?text);
}

public?class?ASensitiveWordsFilterAdaptor?implements?ISensitiveWordsFilter?{
??private?ASensitiveWordsFilter?aFilter;
??public?String?filter(String?text)?{
????String?maskedText?=?aFilter.filterSexyWords(text);
????maskedText?=?aFilter.filterPoliticalWords(maskedText);
????return?maskedText;
??}
}
//...省略BSensitiveWordsFilterAdaptor、CSensitiveWordsFilterAdaptor...

//?擴展性更好，更加符合開閉原則，如果添加一個新的敏感詞過濾系統(tǒng)，
//?這個類完全不需要改動；而且基于接口而非實現(xiàn)編程，代碼的可測試性更好。
public?class?RiskManagement?{?
??private?List<ISensitiveWordsFilter>?filters?=?new?ArrayList<>();
?
??public?void?addSensitiveWordsFilter(ISensitiveWordsFilter?filter)?{
????filters.add(filter);
??}
??
??public?String?filterSensitiveWords(String?text)?{
????String?maskedText?=?text;
????for?(ISensitiveWordsFilter?filter?:?filters)?{
??????maskedText?=?filter.filter(maskedText);
????}
????return?maskedText;
??}
}

3.3 替換依賴的外部系統(tǒng)

把項目中依賴的一個外部系統(tǒng)替換為另一個外部系統(tǒng)時?？蓽p少對代碼改動。

//?外部系統(tǒng)A
public?interface?IA?{
??//...
??void?fa();
}
public?class?A?implements?IA?{
??//...
??public?void?fa()?{?//...?}
}
//?在我們的項目中，外部系統(tǒng)A的使用示例
public?class?Demo?{
??private?IA?a;
??public?Demo(IA?a)?{
????this.a?=?a;
??}
??//...
}
Demo?d?=?new?Demo(new?A());

//?將外部系統(tǒng)A替換成外部系統(tǒng)B
public?class?BAdaptor?implemnts?IA?{
??private?B?b;
??public?BAdaptor(B?b)?{
????this.b=?b;
??}
??public?void?fa()?{
????//...
????b.fb();
??}
}
//?借助BAdaptor，Demo的代碼中，調(diào)用IA接口的地方都無需改動，
//?只需要將BAdaptor如下注入到Demo即可。
Demo?d?=?new?Demo(new?BAdaptor(new?B()));

3.4 兼容老版本接口

在做版本升級的時候，對于一些要廢棄的接口，我們不直接將其刪除，而是暫時保留，并且標注為deprecated，并將內(nèi)部實現(xiàn)邏輯委托為新的接口實現(xiàn)。這樣做的好處是，讓使用它的項目有個過渡期，而不是強制進行代碼修改。這也可以粗略地看作適配器模式的一個應(yīng)用場景。同樣，我還是通過一個例子，來進一步解釋一下。

JDK1.0中包含一個遍歷集合容器的類Enumeration。JDK2.0對這個類進行了重構(gòu)，將它改名為Iterator類，并且對它的代碼實現(xiàn)做了優(yōu)化。但是考慮到如果將Enumeration直接從JDK2.0中刪除，那使用JDK1.0的項目如果切換到JDK2.0，代碼就會編譯不通過。為了避免這種情況的發(fā)生，我們必須把項目中所有使用到Enumeration的地方，都修改為使用Iterator才行。

單獨一個項目做Enumeration到Iterator的替換，勉強還能接受。但是，使用Java開發(fā)的項目太多了，一次JDK的升級，導(dǎo)致所有的項目不做代碼修改就會編譯報錯，這顯然是不合理的。這就是我們經(jīng)常所說的不兼容升級。為了做到兼容使用低版本JDK的老代碼，我們可以暫時保留Enumeration類，并將其實現(xiàn)替換為直接調(diào)用Itertor。代碼示例如下所示：

public?class?Collections?{
??public?static?Emueration?emumeration(final?Collection?c)?{
????return?new?Enumeration()?{
??????Iterator?i?=?c.iterator();
??????
??????public?boolean?hasMoreElments()?{
????????return?i.hashNext();
??????}
??????
??????public?Object?nextElement()?{
????????return?i.next():
??????}
????}
??}
}

3.5 適配不同格式的數(shù)據(jù)

前面我們講到，適配器模式主要用于接口的適配，實際上，它還可以用在不同格式的數(shù)據(jù)之間的適配。比如，把從不同征信系統(tǒng)拉取的不同格式的征信數(shù)據(jù)，統(tǒng)一為相同的格式，以方便存儲和使用。再比如，Java中的Arrays.asList()也可以看作一種數(shù)據(jù)適配器，將數(shù)組類型的數(shù)據(jù)轉(zhuǎn)化為集合容器類型。

List<String>?stooges?=?Arrays.asList("Larry",?"Moe",?"Curly");

4 Java日志設(shè)計

Java日志框架常用的log4j、logback及JDK的JUL(java.util.logging)和Apache的JCL(Jakarta Commons Logging)。

它們提供了相似功能，按級別（debug、info、warn、error……）打印日志，但未實現(xiàn)統(tǒng)一接口。

若項目中用到某組件使用log4j，而項目本身使用logback。將組件引入到項目后，項目就相當于有兩套日志框架。每種日志框架都有自己特有配置方式。所以，要針對每種日志框架編寫不同配置文件（如日志存儲的文件地址、打印日志格式）。若引入多個組件，每個組件使用的日志框架都不一樣，那日志本身的管理工作就變得非常復(fù)雜。為此，必須統(tǒng)一日志打印框架。

Slf4j，類似JDBC規(guī)范，打印日志的統(tǒng)一接口規(guī)范。只定義接口，未提供實現(xiàn)，需配合具體日志框架（log4j、logback等）。Slf4j晚于JUL、JCL、log4j等日志框架，所以，這些日志框架也不可能犧牲版本兼容性，將接口改造成符合Slf4j接口規(guī)范。所以Slf4j不僅提供統(tǒng)一接口定義，還提供針對不同日志框架的適配器。對不同日志框架的接口進行二次封裝，適配成統(tǒng)一接口定義。

slf4j統(tǒng)一接口定義：

//?log4j日志框架的適配器
//?LocationAwareLogger繼承自Logger接口，
//?即Log4jLoggerAdapter實現(xiàn)Logger接口。
package?org.slf4j.impl;
public?final?class?Log4jLoggerAdapter?extends?MarkerIgnoringBase
??implements?LocationAwareLogger,?Serializable?{
??final?transient?org.apache.log4j.Logger?logger;?//?log4j
?
??public?boolean?isDebugEnabled()?{
????return?logger.isDebugEnabled();
??}
?
??public?void?debug(String?msg)?{
????logger.log(FQCN,?Level.DEBUG,?msg,?null);
??}
?
??public?void?debug(String?format,?Object?arg)?{
????if?(logger.isDebugEnabled())?{
??????FormattingTuple?ft?=?MessageFormatter.format(format,?arg);
??????logger.log(FQCN,?Level.DEBUG,?ft.getMessage(),?ft.getThrowable());
????}
??}
?
??public?void?debug(String?format,?Object?arg1,?Object?arg2)?{
????if?(logger.isDebugEnabled())?{
??????FormattingTuple?ft?=?MessageFormatter.format(format,?arg1,?arg2);
??????logger.log(FQCN,?Level.DEBUG,?ft.getMessage(),?ft.getThrowable());
????}
??}
?
??public?void?debug(String?format,?Object[]?argArray)?{
????if?(logger.isDebugEnabled())?{
??????FormattingTuple?ft?=?MessageFormatter.arrayFormat(format,?argArray);
??????logger.log(FQCN,?Level.DEBUG,?ft.getMessage(),?ft.getThrowable());
????}
??}
?
??public?void?debug(String?msg,?Throwable?t)?{
????logger.log(FQCN,?Level.DEBUG,?msg,?t);
??}
}

統(tǒng)一使用Slf4j提供的接口來編寫打印日志的代碼，而具體使用哪種日志框架實現(xiàn)（log4j、logback……），可動態(tài)指定（使用Java SPI），將相應(yīng)SDK導(dǎo)入項目即可。

若老項目無Slf4j，而直接使用JCL，若還想替換成其他日志框架如log4j，咋辦？Slf4j不僅提供了從其他日志框架到Slf4j的適配器，還提供了反向適配器，即從Slf4j到其他日志框架適配。于是，可先將JCL切換為Slf4j，再將Slf4j切換為log4j。經(jīng)過兩次適配器轉(zhuǎn)換，就能將log4j切換為logback。

5 代理 V.S 橋接 V.S 裝飾器 V.S 適配器模式

都可稱為Wrapper模式，即通過Wrapper類二次封裝原始類。代碼結(jié)構(gòu)相似，但要解決的問題、應(yīng)用場景不同。

• ??代理模式不改變原始類接口的條件下，為原始類定義一個代理類，主要為控制訪問，而非加強功能，這是和裝飾器模式的最大不同

• ??橋接模式將接口部分和實現(xiàn)部分分離，讓它們更容易、也相對獨立地改變

• ??裝飾器模式不改變原始類接口的情況下，對原始類功能進行增強，并且支持多個裝飾器的嵌套使用

• ??適配器模式適配器模式是一種事后的補救策略。適配器提供跟原始類不同的接口，而代理模式、裝飾器模式提供的都是跟原始類相同的接口。

6 案例

• ??MediaPlayer?接口

• ??實現(xiàn)?MediaPlayer?接口的實體類?AudioPlayer

默認情況下，AudioPlayer?可以播放 mp3

• ??接口?AdvancedMediaPlayer

• ??實現(xiàn)了?AdvancedMediaPlayer?接口的實體類。該類可以播放 vlc 和 mp4 格式的文件。

我們想要讓?AudioPlayer?播放其他格式的音頻文件。為了實現(xiàn)這個功能，我們需要創(chuàng)建

• ??一個實現(xiàn)了?MediaPlayer?接口的適配器類?MediaAdapter

使用

• ??AdvancedMediaPlayer?對象來播放所需的格式。

AudioPlayer?使用適配器類?MediaAdapter?傳遞所需的音頻類型，不需要知道能播放所需格式音頻的實際類。AdapterPatternDemo，我們的演示類使用?AudioPlayer?類來播放各種格式。

步驟 1

創(chuàng)建接口。

步驟 2

步驟 3

步驟 4

步驟 5

步驟 6

測試類輸出：

實現(xiàn)?Iterable?的?Fibnoacci?生成器

重寫這個類，實現(xiàn)?Iterable?接口？

• ??不過你并不是總擁有源代碼的控制權(quán)

• ??并且，除非必須這么做，否則，我們也不愿意重寫一個類

因此另一種選擇，創(chuàng)建一個 適配器(Adapter) 來實現(xiàn)所需接口。有多種適配器的實現(xiàn)，例如繼承：

在?for-in?語句中使用?IterableFibonacci，必須在構(gòu)造函數(shù)中提供一個邊界值，這樣?hasNext()?才知道何時返回?false，結(jié)束循環(huán)。

7 優(yōu)點

• ??解耦目標類和適配者類，通過引入一個適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼

• ??增加了類的透明性和復(fù)用性，將具體的實現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復(fù)用性

• ??靈活性和擴展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器類，完全符合“開閉原則”

類適配器模式還具有如下優(yōu)點：由于適配器類是適配者類的子類，因此可以在適配器類中置換一些適配者的方法，使得適配器的靈活性更強。

對象適配器模式還具有如下優(yōu)點：一個對象適配器可以把多個不同的適配者適配到同一個目標，也就是說，同一個適配器可以把適配者類和它的子類都適配到目標接口。

8 缺點

• ??類適配器模式Java不支持多繼承，一次最多只能適配一個適配者類，且目標抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標接口

• ??對象適配器模式與類適配器模式相比，要想置換適配者類的方法就很麻煩。若必須置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然后再把適配者類的子類當做真正的適配者進行適配，實現(xiàn)過程較為復(fù)雜

9 適用場景

• ??系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要

• ??想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進的類一起工作

擴展

認適配器模式(Default Adapter Pattern)或缺省適配器模式 當不需要全部實現(xiàn)接口提供的方法時，可先設(shè)計一個抽象類實現(xiàn)接口，并為該接口中每個方法提供一個默認實現(xiàn)（空方法），那么該抽象類的子類可有選擇地覆蓋父類的某些方法來實現(xiàn)需求，它適用于一個接口不想使用其所有的方法的情況。因此也稱為單接口適配器模式。

10 總結(jié)

結(jié)構(gòu)型模式：描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)。適配器模式將一個接口轉(zhuǎn)換成希望的另一個接口，適配器模式使接口不兼容的那些類能協(xié)作，其別名為包裝器。既能作為類結(jié)構(gòu)型模式，也可以作為對象結(jié)構(gòu)型模式。

適配器模式包含四個角色：目標抽象類定義客戶要用的特定領(lǐng)域的接口；適配器類可以調(diào)用另一個接口，作為一個轉(zhuǎn)換器，對適配者和抽象目標類進行適配，它是適配器模式的核心；適配者類是被適配的角色，它定義了一個已經(jīng)存在的接口，這個接口需要適配；在客戶類中針對目標抽象類進行編程，調(diào)用在目標抽象類中定義的業(yè)務(wù)方法。

• ??在類適配器模式中，適配器類實現(xiàn)了目標抽象類接口并繼承了適配者類，并在目標抽象類的實現(xiàn)方法中調(diào)用所繼承的適配者類的方法；在對象適配器模式中，適配器類繼承了目標抽象類并定義了一個適配者類的對象實例，在所繼承的目標抽象類方法中調(diào)用適配者類的相應(yīng)業(yè)務(wù)方法。

• ??適配器模式的主要優(yōu)點是將目標類和適配者類解耦，增加了類的透明性和復(fù)用性，同時系統(tǒng)的靈活性和擴展性都非常好，更換適配器或者增加新的適配器都非常方便，符合“開閉原則”；類適配器模式的缺點是適配器類在很多編程語言中不能同時適配多個適配者類，對象適配器模式的缺點是很難置換適配者類的方法。

• ??適配器模式適用情況包括：系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要；想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類一起工作。

適配器模式是用來做適配，它將不兼容的接口轉(zhuǎn)換為可兼容的接口，讓原本由于接口不兼容而不能一起工作的類可以一起工作。適配器模式有兩種實現(xiàn)方式：類適配器和對象適配器。其中，類適配器使用繼承關(guān)系來實現(xiàn)，對象適配器使用組合關(guān)系來實現(xiàn)。

一般來說，適配器模式可以看作一種“補償模式”，用來補救設(shè)計上的缺陷。應(yīng)用這種模式算是“無奈之舉”，如果在設(shè)計初期，我們就能協(xié)調(diào)規(guī)避接口不兼容的問題，那這種模式就沒有應(yīng)用的機會了。

出現(xiàn)接口不兼容的場景：

• ??封裝有缺陷的接口設(shè)計

• ??統(tǒng)一多個類的接口設(shè)計

• ??替換依賴的外部系統(tǒng)

• ??兼容老版本接口

• ??適配不同格式的數(shù)據(jù)