設計模式：擴充卡模式

擴充卡模式的原理與實作

擴充卡模式的英文翻譯是 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 接口定義大部分都不相同，那我們推薦使用對象擴充卡，因為組合結構相對于繼承更加靈活。

擴充卡模式應用場景總結

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

擴充卡模式的應用場景是“接口不相容”。那在實際的開發中，什麼情況下才會出現接口不相容呢？

封裝有缺陷的接口設計

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

舉個例子：

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...
	}
}
           

統一多個類的接口設計

某個功能的實作依賴多個外部系統（或者說類）。通過擴充卡模式，将它們的接口适配為統一的接口定義，然後我們就可以使用多态的特性來複用代碼邏輯。

舉個例子：假設我們的系統要對使用者輸出的文本内容做敏感詞過濾，為了提高過濾的召回率，我們引入了多個第三方敏感詞過濾系統，依次對使用者輸入的内容進行過濾，過濾掉盡可能多的敏感詞。但是，每個系統提供的過濾接口都是不同的，這就意味着我們沒法複用一套邏輯來調用各個系統。這個時候，我們可以用擴充卡模式，将所有系統的接口适配為統一的接口定義，這樣我們可以複用調用敏感詞過濾的代碼

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;
	}
}
           

替換依賴的外部系統

當我們把項目中依賴的一個外部系統替換為另一個外部系統的時候，利用擴充卡模式，可以減少對代碼的改動。如下：

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

相容老版本接口

在做版本更新的時候，對于一些要廢棄的接口，我們不直接将其删除，而是暫時保留，并且标注為 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():
		}
	}
  }
}
           

适配不同格式的資料

擴充卡模式除了可以用于接口的适配外，還可以用在不同格式的資料間的适配。比如，把從不同征信系統拉取不同格式的征信資料，統一為相同的格式，以友善存儲和使用。比如Java 中的 Arrays.asList() 也可以看作一種資料擴充卡，将數組類型的資料轉化為集合容器類型。

剖析擴充卡模式在 Java 日志中的應用

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

大部分日志架構都提供了相似的功能，比如按照不同級别（debug、info、warn、erro……）列印日志等，但它們并沒有實作統一的接口。這主要可能是曆史原因，它不想JDBC那樣，一開始就制定了資料庫操作的接口規範。

如果我們隻是開發一個自己用的項目，那什麼日志架構都可以。但是如果我們開發的是一個內建到其他系統的元件、架構、類庫等，那日志架構的選擇就沒有那麼随意了。

比如，項目中用到的某個元件使用 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……），是可以動态地指定的，隻需要将相應的 SDK 導入到項目中即可。

代理、橋接、裝飾器、擴充卡 4 種設計模式的差別

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

盡管代碼結構相似，但這 4 種設計模式的用意完全不同，也就是說要解決的問題、應用場景不同，這也是它們的主要差別。

• 代理模式：代理模式在不改變原始類接口的條件下，為原始類定義一個代理類，主要目的是控制通路，而非加強功能。這是它跟裝飾器模式最大的不同
• 橋接模式：橋接模式的目的是将接口部分和實作部分分離，進而讓它們可以更加容易、也相對獨立的加以改變
• 裝飾器模式：裝飾器模式在不改變原始類接口的情況下，對原始類功能進行增強，并且支援多個裝飾器模式的嵌套使用
• 擴充卡模式：擴充卡模式是一種事後的補救政策。擴充卡提供跟原始類不同的接口，而代理模式、裝飾器模式提供的都是跟原始類相同的接口。

總結

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

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

那在實際的開發中，什麼情況下才會出現接口不相容呢？

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