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

1 簡介

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

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

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

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

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

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

定義

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

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

角色

• ? Target：目標(biāo)抽象類
• ? Adapter：適配器類
• ? Adaptee：適配者類
• ? Client：客戶類

2 實(shí)現(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() {
    //...重新實(shí)現(xiàn)f2()...
  }
  
  // 這里fc()不需要實(shí)現(xiàn)，直接繼承自Adaptee，這是跟對象適配器最大的不同點(diǎn)
}

2.2 對象適配器

使用組合關(guān)系來實(shí)現(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() {
    //...重新實(shí)現(xiàn)f2()...
  }
  
  public void fc() {
    adaptee.fc();
  }
}

如何選型？判斷標(biāo)準(zhǔn)：

• ? Adaptee接口不多，則兩種皆可
• ? Adaptee接口很多&&Adaptee和ITarget接口定義大部分相同，推薦類適配器，因?yàn)锳daptor復(fù)用父類Adaptee接口，比起對象適配器，Adaptor代碼量更少
• ? Adaptee接口很多&&且Adaptee和ITarget接口定義大不相同，推薦對象適配器，因?yàn)榻M合相比繼承更靈活

3 適用場景

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

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

3.1 封裝缺陷接口

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

// 該類來自外部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)一多個(gè)類的接口設(shè)計(jì)

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

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

// 未使用適配器模式之前的代碼：代碼的可測試性、擴(kuò)展性不好
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;
  }
}

// 使用適配器模式進(jìn)行改造
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...

// 擴(kuò)展性更好，更加符合開閉原則，如果添加一個(gè)新的敏感詞過濾系統(tǒng)，
// 這個(gè)類完全不需要改動；而且基于接口而非實(shí)現(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)

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

// 外部系統(tǒng)A
public interface IA {
  //...
  void fa();
}
public class A implements IA {
  //...
  public void fa() { //... }
}
// 在我們的項(xiàng)目中，外部系統(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 兼容老版本接口

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

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

單獨(dú)一個(gè)項(xiàng)目做Enumeration到Iterator的替換，勉強(qiáng)還能接受。但是，使用Java開發(fā)的項(xiàng)目太多了，一次JDK的升級，導(dǎo)致所有的項(xiàng)目不做代碼修改就會編譯報(bào)錯(cuò)，這顯然是不合理的。這就是我們經(jīng)常所說的不兼容升級。為了做到兼容使用低版本JDK的老代碼，我們可以暫時(shí)保留Enumeration類，并將其實(shí)現(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í)際上，它還可以用在不同格式的數(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è)計(jì)

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

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

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

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

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

// log4j日志框架的適配器
// LocationAwareLogger繼承自Logger接口，
// 即Log4jLoggerAdapter實(shí)現(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提供的接口來編寫打印日志的代碼，而具體使用哪種日志框架實(shí)現(xiàn)（log4j、logback……），可動態(tài)指定（使用Java SPI），將相應(yīng)SDK導(dǎo)入項(xiàng)目即可。

若老項(xiàng)目無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)用場景不同。

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

6 案例

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

默認(rèn)情況下，AudioPlayer 可以播放 mp3

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

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

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

使用

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

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

適配器模式的 UML 圖

步驟 1

創(chuàng)建接口。

步驟 2

步驟 3

步驟 4

步驟 5

步驟 6

測試類輸出：

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

重寫這個(gè)類，實(shí)現(xiàn) Iterable 接口？

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

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

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

7 優(yōu)點(diǎn)

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

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

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

8 缺點(diǎn)

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

9 適用場景

• ? 系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要
• ? 想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作

擴(kuò)展

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

10 總結(jié)

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

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

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

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

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

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

• ? 封裝有缺陷的接口設(shè)計(jì)
• ? 統(tǒng)一多個(gè)類的接口設(shè)計(jì)
• ? 替換依賴的外部系統(tǒng)
• ? 兼容老版本接口
• ? 適配不同格式的數(shù)據(jù)