1 簡介

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

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

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

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

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

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

定義

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

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

角色

• ? Target：目標抽象類
• ? Adapter：適配器類
• ? Adaptee：適配者類
• ? Client：客戶類

2 實現方式

2.1 類適配器

基于繼承。

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

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

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

2.2 對象適配器

使用組合關系來實現。

// 對象適配器：基于組合
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() {
    //...重新實現f2()...
  }
  
  public void fc() {
    adaptee.fc();
  }
}

如何選型？判斷標準：

• ? Adaptee接口不多，則兩種皆可
• ? Adaptee接口很多&&Adaptee和ITarget接口定義大部分相同，推薦類適配器，因為Adaptor復用父類Adaptee接口，比起對象適配器，Adaptor代碼量更少
• ? Adaptee接口很多&&且Adaptee和ITarget接口定義大不相同，推薦對象適配器，因為組合相比繼承更靈活

3 適用場景

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

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

3.1 封裝缺陷接口

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

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

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

// 適配器模式重構
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 統一多個類的接口設計

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

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

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

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

public class CSensitiveWordsFilter { // C敏感詞過濾系統提供的接口
  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 { // 統一接口定義
  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...

// 擴展性更好，更加符合開閉原則，如果添加一個新的敏感詞過濾系統，
// 這個類完全不需要改動；而且基于接口而非實現編程，代碼的可測試性更好。
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 替換依賴的外部系統

把項目中依賴的一個外部系統替換為另一個外部系統時。可減少對代碼改動。

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

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

3.4 兼容老版本接口

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

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

單獨一個項目做Enumeration到Iterator的替換，勉強還能接受。但是，使用Java開發的項目太多了，一次JDK的升級，導致所有的項目不做代碼修改就會編譯報錯，這顯然是不合理的。這就是我們經常所說的不兼容升級。為了做到兼容使用低版本JDK的老代碼，我們可以暫時保留Enumeration類，并將其實現替換為直接調用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 適配不同格式的數據

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

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

4 Java日志設計

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

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

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

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

slf4j統一接口定義：

// log4j日志框架的適配器
// LocationAwareLogger繼承自Logger接口，
// 即Log4jLoggerAdapter實現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);
  }
}

統一使用Slf4j提供的接口來編寫打印日志的代碼，而具體使用哪種日志框架實現（log4j、logback……），可動態指定（使用Java SPI），將相應SDK導入項目即可。

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

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

都可稱為Wrapper模式，即通過Wrapper類二次封裝原始類。代碼結構相似，但要解決的問題、應用場景不同。

• ? 代理模式不改變原始類接口的條件下，為原始類定義一個代理類，主要為控制訪問，而非加強功能，這是和裝飾器模式的最大不同
• ? 橋接模式將接口部分和實現部分分離，讓它們更容易、也相對獨立地改變
• ? 裝飾器模式不改變原始類接口的情況下，對原始類功能進行增強，并且支持多個裝飾器的嵌套使用
• ? 適配器模式適配器模式是一種事后的補救策略。適配器提供跟原始類不同的接口，而代理模式、裝飾器模式提供的都是跟原始類相同的接口。

6 案例

• ? MediaPlayer 接口
• ? 實現 MediaPlayer 接口的實體類 AudioPlayer

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

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

我們想要讓 AudioPlayer 播放其他格式的音頻文件。為了實現這個功能，我們需要創建

• ? 一個實現了 MediaPlayer 接口的適配器類 MediaAdapter

使用

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

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

適配器模式的 UML 圖

步驟 1

創建接口。

步驟 2

步驟 3

步驟 4

步驟 5

步驟 6

測試類輸出：

實現 Iterable 的 Fibnoacci 生成器

重寫這個類，實現 Iterable 接口？

• ? 不過你并不是總擁有源代碼的控制權
• ? 并且，除非必須這么做，否則，我們也不愿意重寫一個類

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

在 for-in 語句中使用 IterableFibonacci，必須在構造函數中提供一個邊界值，這樣 hasNext() 才知道何時返回 false ，結束循環。

7 優點

• ? 解耦目標類和適配者類，通過引入一個適配器類來重用現有的適配者類，而無須修改原有代碼
• ? 增加了類的透明性和復用性，將具體的實現封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復用性
• ? 靈活性和擴展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎上增加新的適配器類，完全符合“開閉原則”

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

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

8 缺點

• ? 類適配器模式Java不支持多繼承，一次最多只能適配一個適配者類，且目標抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標接口
• ? 對象適配器模式與類適配器模式相比，要想置換適配者類的方法就很麻煩。若必須置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然后再把適配者類的子類當做真正的適配者進行適配，實現過程較為復雜

9 適用場景

• ? 系統需要使用現有的類，而這些類的接口不符合系統的需要
• ? 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作

擴展

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

10 總結

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

適配器模式包含四個角色：目標抽象類定義客戶要用的特定領域的接口；適配器類可以調用另一個接口，作為一個轉換器，對適配者和抽象目標類進行適配，它是適配器模式的核心；適配者類是被適配的角色，它定義了一個已經存在的接口，這個接口需要適配；在客戶類中針對目標抽象類進行編程，調用在目標抽象類中定義的業務方法。

• ? 在類適配器模式中，適配器類實現了目標抽象類接口并繼承了適配者類，并在目標抽象類的實現方法中調用所繼承的適配者類的方法；在對象適配器模式中，適配器類繼承了目標抽象類并定義了一個適配者類的對象實例，在所繼承的目標抽象類方法中調用適配者類的相應業務方法。
• ? 適配器模式的主要優點是將目標類和適配者類解耦，增加了類的透明性和復用性，同時系統的靈活性和擴展性都非常好，更換適配器或者增加新的適配器都非常方便，符合“開閉原則”；類適配器模式的缺點是適配器類在很多編程語言中不能同時適配多個適配者類，對象適配器模式的缺點是很難置換適配者類的方法。
• ? 適配器模式適用情況包括：系統需要使用現有的類，而這些類的接口不符合系統的需要；想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類一起工作。

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

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

出現接口不兼容的場景：

• ? 封裝有缺陷的接口設計
• ? 統一多個類的接口設計
• ? 替換依賴的外部系統
• ? 兼容老版本接口
• ? 適配不同格式的數據