設計模式之美 - 51 | 適配器模式：代理、適配器、橋接、裝飾，這四個模式有何區別？

這系列相關博客，參考 設計模式之美

前面幾節課我們學習了代理模式、橋接模式、裝飾器模式，今天，我們再來學習一個比較常用的結構型模式：適配器模式。這個模式相對來說還是比較簡單、好理解的，應用場景也很具體，總體上來講比較好掌握。

關於適配器模式，今天我們主要學習它的兩種實現方式，類適配器和對象適配器，以及 5種常見的應用場景。同時，我還會通過剖析 slf4j 日誌框架，來給你展示這個模式在真實項目中的應用。除此之外，在文章的最後，我還對代理、橋接、裝飾器、適配器，這 4 種代碼結構非常相似的設計模式做簡單的對比，對這幾節內容做一個簡單的總結。

話不多說，讓我們正式開始今天的學習吧！

適配器模式的原理與實現

適配器模式的英文翻譯是 Adapter Design Pattern。顧名思義，這個模式就是用來做適配的，它將不兼容的接口轉換爲可兼容的接口，讓原本由於接口不兼容而不能一起工作的類可以一起工作。對於這個模式，有一個經常被拿來解釋它的例子，就是 USB 轉接頭充當適配器，把兩種不兼容的接口，通過轉接變得可以一起工作。

原理很簡單，我們再來看下它的代碼實現。適配器模式有兩種實現方式：類適配器和對象適配器。其中，類適配器使用繼承關係來實現，對象適配器使用組合關係來實現。具體的代碼實現如下所示。其中，ITarget 表示要轉化成的接口定義。Adaptee 是一組不兼容 ITarget接口定義的接口，Adaptor 將 Adaptee 轉化成一組符合 ITarget 接口定義的接口。

// 類適配器: 基於繼承
public interface ITarget {
	void f1();
	void f2();
	void fc();
}

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

public class Adaptor extends Adaptee implements ITarget {
	public void f1() {
		super.fa();
	}
	
	public void f2() {
		//...重新實現f2()...
	}
	
	// 這裏fc()不需要實現，直接繼承自Adaptee，這是跟對象適配器最大的不同點
}

// 對象適配器：基於組合
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 和 ITarget 的契合程度。

• 如果 Adaptee 接口並不多，那兩種實現方式都可以。

• 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定義大部分都相同，那我們推薦使用類適配器，因爲 Adaptor 複用父類 Adaptee 的接口，比起對象適配器的實現方式，Adaptor 的代碼量要少一些。

• 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定義大部分都不相同，那我們推薦使用對象適配器，因爲組合結構相對於繼承更加靈活。

適配器模式應用場景總結

原理和實現講完了，都不復雜。我們再來看，到底什麼時候會用到適配器模式呢？

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

前面我們反覆提到，適配器模式的應用場景是“接口不兼容”。那在實際的開發中，什麼情況下才會出現接口不兼容呢？我建議你先自己思考一下這個問題，然後再來看我下面的總結。

1. 封裝有缺陷的接口設計

假設我們依賴的外部系統在接口設計方面有缺陷（比如包含大量靜態方法），引入之後會影響到我們自身代碼的可測試性。爲了隔離設計上的缺陷，我們希望對外部系統提供的接口進行二次封裝，抽象出更好的接口設計，這個時候就可以使用適配器模式了。

具體我還是舉個例子來解釋一下，你直接看代碼應該會更清晰。具體代碼如下所示：

public class CD { //這個類來自外部sdk，我們無權修改它的代碼
	//...
	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...
	}
}

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. 替換依賴的外部系統

當我們把項目中依賴的一個外部系統替換爲另一個外部系統的時候，利用適配器模式，可以減少對代碼的改動。具體的代碼示例如下所示：

// 外部系統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()));

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():
			}
		}
	}
}

5. 適配不同格式的數據

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

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

剖析適配器模式在 Java 日誌中的應用

Java 中有很多日誌框架，在項目開發中，我們常常用它們來打印日誌信息。其中，比較常用的有 log4j、logback，以及 JDK 提供的 JUL(java.util.logging) 和 Apache 的 JCL(Jakarta Commons Logging) 等。

大部分日誌框架都提供了相似的功能，比如按照不同級別（debug、info、warn、erro……）打印日誌等，但它們卻並沒有實現統一的接口。這主要可能是歷史的原因，它不像 JDBC 那樣，一開始就制定了數據庫操作的接口規範。

如果我們只是開發一個自己用的項目，那用什麼日誌框架都可以，log4j、logback 隨便選一個就好。但是，如果我們開發的是一個集成到其他系統的組件、框架、類庫等，那日誌框架的選擇就沒那麼隨意了。

比如，項目中用到的某個組件使用 log4j 來打印日誌，而我們項目本身使用的是logback。將組件引入到項目之後，我們的項目就相當於有了兩套日誌打印框架。每種日誌框架都有自己特有的配置方式。所以，我們要針對每種日誌框架編寫不同的配置文件（比如，日誌存儲的文件地址、打印日誌的格式）。如果引入多個組件，每個組件使用的日誌框架都不一樣，那日誌本身的管理工作就變得非常複雜。所以，爲了解決這個問題，我們需要統一日誌打印框架。

如果你是做 Java 開發的，那 Slf4j 這個日誌框架你肯定不陌生，它相當於 JDBC 規範，提供了一套打印日誌的統一接口規範。不過，它只定義了接口，並沒有提供具體的實現，需要配合其他日誌框架（log4j、logback……）來使用。

不僅如此，Slf4j 的出現晚於 JUL、JCL、log4j 等日誌框架，所以，這些日誌框架也不可能犧牲掉版本兼容性，將接口改造成符合 Slf4j 接口規範。Slf4j 也事先考慮到了這個問題，所以，它不僅僅提供了統一的接口定義，還提供了針對不同日誌框架的適配器。對不同日誌框架的接口進行二次封裝，適配成統一的 Slf4j 接口定義。具體的代碼示例如下所示：

// slf4j統一的接口定義
package org.slf4j;
public interface Logger {
	public boolean isTraceEnabled();
	public void trace(String msg);
	public void trace(String format, Object arg);
	public void trace(String format, Object arg1, Object arg2);
	public void trace(String format, Object[] argArray);
	public void trace(String msg, Throwable t);
	
	public boolean isDebugEnabled();
	public void debug(String msg);
	public void debug(String format, Object arg);
	public void debug(String format, Object arg1, Object arg2)
	public void debug(String format, Object[] argArray)
	public void debug(String msg, Throwable t);
	//...省略info、warn、error等一堆接口
}

// log4j日誌框架的適配器
// Log4jLoggerAdapter實現了LocationAwareLogger接口，
// 其中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。

代理、橋接、裝飾器、適配器 4 種設計模式的區別

代理、橋接、裝飾器、適配器，這 4 種模式是比較常用的結構型設計模式。它們的代碼結構非常相似。籠統來說，它們都可以稱爲 Wrapper 模式，也就是通過 Wrapper 類二次封裝原始類。

儘管代碼結構相似，但這 4 種設計模式的用意完全不同，也就是說要解決的問題、應用場景不同，這也是它們的主要區別。這裏我就簡單說一下它們之間的區別。

代理模式：代理模式在不改變原始類接口的條件下，爲原始類定義一個代理類，主要目的是控制訪問，而非加強功能，這是它跟裝飾器模式最大的不同。

橋接模式：橋接模式的目的是將接口部分和實現部分分離，從而讓它們可以較爲容易、也相對獨立地加以改變。

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

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

重點回顧

好了，今天的內容到此就講完了。讓我們一塊來總結回顧一下，你需要重點掌握的內容。

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

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

那在實際的開發中，什麼情況下才會出現接口不兼容呢？我總結下了下面這樣 5 種場景：

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

課堂討論

今天我們講到，適配器有兩種實現方式：類適配器、對象適配器。那我們之前講到的代理模式、裝飾器模式，是否也同樣可以有兩種實現方式（類代理模式、對象代理模式，以及類裝飾器模式、對象裝飾器模式）呢？