設計模式之配接器模式-有解無憂

本文通過老王使用紙質書籍閱讀小王使用電子書籍的故事，詳細說明設計模式中的結構型設計模式之配接器模式，分別對物件配接器和類配接器代碼實作，最后為了加深理解，會列舉配接器設計模式在JDK和Spring原始碼中的應用，

讀者可以拉取完整代碼到本地進行學習，實作代碼均測驗通過后上傳到碼云，

一、引出問題

自從小王被老王趕出家門以后，老王過了幾天舒心的日子，在家里的書架上買了許許多多的紙質書，

有一天，小王過夠了野人生活回來了，小王也是一個喜歡讀書的人，但是小王不喜歡紙質書，就要求老王將這些書換成電子版，

老王立馬就不開心了，這是我不知道花費多少個日夜才設計好的書架，給你換成電子版的不僅要花費我大量的精力改變原有書架的結構，再想找我想看的書得有多難，而且老李來了想看紙質版怎么辦，我還要再換回去嗎？

小王隨即想到了一種解決思路：這些書現在符合你的風格，應該設計一種模式，讓這些書也能符合我的需求，讓我們倆可以在一起讀書，既不改變你的書架結構，又能擴展它的功能，

老王滿意的點了點頭，你說的不錯，這實際上就是結構型設計模式中的配接器模式，

二、概念與使用

參考Gof中對配接器設計模式的概念：將一個類的介面轉化成客戶希望的另一個介面，由于介面不兼容而不能一起作業的類可以一起作業，

很顯然，在配接器設計模式中應該有三個角色，

目標類：Target，該角色把其他類轉換為我們期望的介面，可以是一個抽象類或介面，也可以是具體類，
被適配者類（源）: Adaptee ，原有的介面，也是希望被適配的介面，
配接器： Adapter, 將被適配者和目標抽象類組合到一起的類，

在我們的實際案例中，老王的紙質書很明顯應該是屬于被適配者，小王的電子版就是目標類，配接器應該是能呼叫老王的紙質書，并使用一些相關的業務方法轉化成電子版，比如呼叫老王書之前買一個掃描儀，在老王書調出來以后掃描書籍，

既然配接器中要呼叫老王的紙質書，呼叫它的方法應該是有兩種實作方式，

一是直接繼承老王，那樣就可以直接呼叫老王的方法了，

二是在配接器中創建老王的物件，然后再呼叫老王的方法，

這其實對應了配接器的兩種方式，根據配接器類與適配者類的關系不同，配接器模式可分為物件配接器和類配接器兩種，在物件配接器模式中，配接器與適配者之間是關聯關系；在類配接器模式中，配接器與適配者之間是繼承（或實作）關系，

我們先看類配接器實作方式：

被適配者類：

/**
 * 源物件
 * @author tcy
 * @Date 04-08-2022
 */
public class AdapteePaperReading {

    public void readPaper(){
        System.out.println("這是老王讀的紙質書...(被適配者方法)");
    }
}

目標物件：

/**
 * 目標物件
 */
public interface TargetOnlineReading {
    public void ReadOnline();
}

配接器：

/**
 * @author tcy
 * @Date 04-08-2022
 */
public class Adapter extends AdapteePaperReading implements TargetOnlineReading{
    @Override
    public void ReadOnline() {

        System.out.println("買一個掃描儀...");
        readPaper();
        System.out.println("拿到紙質書掃描為電子書...");
    }


}

客戶端：

/**
 * @author tcy
 * @Date 04-08-2022
 */
public class Client {

    public static void main(String[] args) {
        Adapter adapter=new Adapter();
        adapter.ReadOnline();

    }
}

以上就實作類配接器，如果我們要實作物件配接器也很簡單，目標物件和被適配者都不變，需要改變的是配接器代碼

/**
 * @author tcy
 * @Date 04-08-2022
 */
public class Adapter implements TargetOnlineReading {

    // 適配者是物件配接器的一個屬性
    private AdapteePaperReading adaptee = new AdapteePaperReading();

    @Override
    public void ReadOnline() {

        System.out.println("買一個掃描儀...");
        adaptee.readPaper();
        System.out.println("拿到紙質書掃描為電子書...");
    }
}

這樣老王和小王就能在一起讀書了，但這種方式只能作為系統的一種補救措施，而不是在系統設計之初就考慮這種方式，如果老王有十個八個兒子都要求按照他們的習慣來，那系統就會相當的復雜，無異于一場災難，而是應該考慮重做書架，將各種情況都考慮進去，

需要說明的是，類配接器之間的耦合度比后者高，且要求程式員了解現有組件庫中的相關組件的內部結構，所以應用相對較少些，

三、應用

案例有一些生硬，為了加深對配接器設計模式的把握，我們介紹該模式在Jdk原始碼和Spring中的應用，

1、JDK應用

JDK使用配接器的典型例子是Java執行緒池FutureTask類，我們知道通過實作介面實作多執行緒一共有兩種方式，Runnable介面和Callable介面，

FutrueTask類中有兩個構造方法：

構造方法一：傳入引數為Callable介面

// 這是FutureTask的構造方法一
public FutureTask(Callable<V> callable) {
    if (callable == null)
        throw new NullPointerException();
    this.callable = callable;
    this.state = NEW;     
}

構造方法二：傳入的引數為Runnable介面

// 這是FutureTask的構造方法二
public FutureTask(Runnable runnable, V result) {
	// 呼叫Executors類中的callable方法進行轉化
    this.callable = Executors.callable(runnable, result);
    this.state = NEW;   
}

在構造方法中實際上加傳入的Runnable任務在內部統一被轉換為Callable任務，

可以看到這里采用的是配接器模式，呼叫RunnableAdapter<T>(task, result)方法來適配，實作如下:

static final class RunnableAdapter<T> implements Callable<T> {
    final Runnable task;
    final T result;
    RunnableAdapter(Runnable task, T result) {
        this.task = task;
        this.result = result;
    }
    public T call() {
        task.run();
        return result;
    }
}

這樣無論是傳入Runnalbe還是Callable都能適配任務，這個配接器很簡單，就是簡單的實作了Callable介面，在call()實作中呼叫Runnable.run()方法，然后把傳入的result作為任務的結果回傳，

通過這么一個簡單案例可以加深對配接器模式的理解，

2、SpringAOP應用

我們知道在Spring的Aop中，使用的 Advice（通知）來增強被代理類的功能，

其中Advice的型別有：BeforeAdvice（在執行切點前的通知）、AfterReturningAdvice（在運行完切點完未回傳之前）、ThrowsAdvice（在運行完切點時拋出例外進行的通知），AfterAdvice（執行完該切點后，進行的通知）、Around advice（包裹一個方法的執行）

在每個型別 Advice 都有對應的攔截器，MethodBeforeAdviceInterceptor、AfterReturningAdviceInterceptor、 ThrowsAdviceInterceptor

Spring需要將每個 Advice 都封裝成對應的攔截器型別，回傳給容器，這時候采用的就是配接器型別，

Advice 就相當于適配者，對應的攔截器型別就是目標類，

限于篇幅，有興趣的讀者可以到Spring原始碼中了解具體程序，

3、SpringMVC應用

Spring MVC中的配接器模式主要用于執行目標 Controller 中的請求處理方法，

在Spring MVC中，DispatcherServlet 作為用戶，HandlerAdapter 作為期望介面，具體的配接器實作類用于對目標類進行適配，Controller 作為需要適配的類，

當Spring容器啟動后，會將所有定義好的配接器物件存放在一個List集合中，當一個請求來臨時，DispatcherServlet 會通過 handler 的型別找到對應配接器，并將該配接器物件回傳給用戶，然后就可以統一通過配接器的 hanle() 方法來呼叫 Controller 中的用于處理請求的方法，

通過配接器模式我們將所有的 controller 統一交給 HandlerAdapter 處理，免去了寫大量的 if-else 陳述句對 Controller 進行判斷，也更利于擴展新的 Controller 型別，

單純的說蒼白無力，我們手寫實作SpringMVC的核心流程，完整代碼已經上傳到碼云，

四、總結

既然配接器模式可以擴展原有類的功能，那它和代理模式在一定程度上不是重合了嗎？貌似擴展老王的書架使用代理模式同樣是可以實作，

其實我們看結構型設計模式的定義：結構型模式涉及到如何組合類和類以獲得更大的結構，結構型類模式采用繼承機制來組****合介面或實作，

代理模式與配接器模式都分別有繼承、介面方式實作的子分類模式，基于介面實作的代理模式稱為靜態代理模式、JDK（動態）代理模式，基于繼承實作的代理模式稱為Cglib(動態)代理模式，

基于介面(同時含類繼承)實作的配接器模式稱為類配接器模式，（只）基于繼承（使用委托）實作的配接器模式稱為類配接器模式，

代理模式是為其他類提供一種代理以控制對這個類的訪問，我們不直接去接觸目標類，而是直接操作代理類，代理類再去操作目標類，因為不直接接觸目標類，因此我們可以在代理類的同名方法中添加或洗掉功能模塊，而不用去修改目標類的原方法，

而配接器模式則主要是協調現實與需求的差異，減少對已有代碼的改動，適配不同的介面、型別別，

專案實施中可能會出現這樣的情況：當前已完成的專案的某一個包內的各個類實作了一些特定的介面，而客戶提出了新的需求，要求實作他所指定的那些介面（拋棄原有的方法或介面），但其業務細節卻是相同、完全一樣的，此時，我們可能并不想復制粘貼原代碼到新的方法中去，這就需要將一個類的介面轉換成新需求的另一個介面，

實作方式有很多，沒有必要咬文嚼字糾結使用哪種設計模式，設計模式本身就是很相似，只要能簡潔開發流程，讓我們的代碼更好的作業就是完美的，具體使用哪一種就需要讀者熟練掌握各種設計模式了，并認真體會他們各自的優勢，

推薦讀者，參考軟體設計七大原則認真閱讀往期的文章，認真體會，

創建型設計模式：

一、設計模式之工廠方法和抽象工廠

二、設計模式之單例和原型

三、設計模式之建造者模式

結構型設計模式：

四、設計模式之代理模式

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/501017.html

標籤：其他

上一篇：（前端）「狀態」設計模式在專案開發中的應用

下一篇：面向物件的基礎知識