編碼中的Adapter，不僅是一種設計模式，更是一種架構理念與解決方案

語言: CN / TW / HK

時間 2022-09-27 08:12:00 博客園精華區

大家好，又見面了。

不知道下面這玩意大家有沒有見過或者使用過？這是一個 插座轉換器 。我們都知道日常使用的是 220v 的交流電，而國外不同國家使用的電流電壓是不一樣的（比如日本使用的是 110v ）、且插座的接口樣式也是各不相同的（比如歐洲國家使用的是兩個 小圓柱 狀的插頭接口），如果我們到別的國家去旅行的時候，藉助這個插座轉換器，就可以讓我們的手機充電器在國外也能正常使用了。

當然，除了使用插座轉換器，還有個方法也可以讓我們出國之後正常的使用各種電子產品，那就是在當地 重新買一套 ！顯然，這樣的成本就會非常巨大，明顯不符合我們勤（ nang ）儉（ zhong ）持（ xiu ）家（ se ）的特徵。

看過我前面的文章的小夥伴應該知道，我的文章中一直反覆的在闡述自己的一個觀念，即“ 編碼源於生活 ” ，這裏依舊不例外。現實生活中的樸素哲學思維，在代碼世界中其實也無時無刻不在體現着。上面舉的例子，在我們的項目中又何嘗不是在頻繁上演此類情況呢？

我們先按照原有的業務邏輯實現了一套代碼，後來又來了個新的需求，如果重新開發一套需要投入大量的人力物力，所以首選方案就是去思考如何去複用已有的邏輯，以最小的代價將業務對接適配使用現有的邏輯去實現。

本篇文章中，我們就從這個“插座轉換器”來作為切入點，聊一聊在軟件系統中無處不在的“插座轉換器” —— 編碼中的適配器（ Adapter ）。選定以 Adapter 為題材進行闡述，並非是因為 Adapter 在技術實現上有多複雜，其實 Adapter 真正實現起來是非常簡單的，而且很多人有意或無意中其實也都在使用。更多的是想一起探討這種 藉助Adapter來複用與兼容已有邏輯的思路 ，以及如何 利用Adapter來踐行OCP（開閉原則）的系統架構設計理念 。

Adapter的百媚千姿

新瓶舊酒：複用現成的實現邏輯

新瓶裝舊酒，在我們的系統裏面是一個很“節省”的操作，可以讓我們基於一個現有的能力快速的封裝提供出一個全新的業務功能，當然有的時候，系統現有的能力可能會某些方面無法完全滿足新業務的需求，需要做一些轉換適配處理。

舉個例子：

一個視頻網站，原先已有一個評論能力，用户可以在視頻下方發表評論，然後評論內容以列表的形式展示在視頻下方頁面上。現在需要開發一個新功能，支持視頻發送彈幕能力，並將彈幕顯示在視頻播放畫面上。

從需求功能上來説，評論與彈幕有很多相似之處。對後端而言，其處理邏輯與存儲數據結構幾乎都是相同的，只是在數據 列表API 實現的時候，需要過濾出評論信息展示到評論區、或者過濾出彈幕信息顯示到視頻畫面上。但是由於彈幕信息有一些特殊的屬性，又沒法直接完全使用現有的評論接口，比如彈幕可能會設置顯示在屏幕的位置、彈幕的字體顏色等等。這種情況下，我們可以通過構造個 Adapter 適配器的方式，在複用已有評論能力的基礎上，順便擴展實現需要的彈幕新特性。

如上圖所示，我們可以在 Adapter 中封裝擴展彈幕需要的新特性，然後對於數據存儲等邏輯則直接複用已有的評論功能處理邏輯，這樣就可以大大減少我們的開發工作量、後續也只需要維護一套主體代碼即可。

負重前行：兼容歷史版本

和上面討論的場景相反，實際開發中還有一種非常常見的情況，就是原先的時候實現了一套業務邏輯，然後因為業務變化或者系統重構，需要對底層具體實現邏輯進行大改。這種情況下，為了保證此前調用該API的業務可以正常使用，通常有兩種思路：

保持原先的內容不動，完全 另起爐灶 全新實現一套，然後兩套邏輯並存，同時維護；
按照新的邏輯去實現，並將原先的對外API適配轉換對接使用新邏輯實現。

顯然，從成本與可維護性層面考慮， 思路2 更為可行、更加經濟。

對比我們文首舉的那個“插頭轉換器”的例子，我們可以把圖中 V1版本業務邏輯 當做我們國內的手機充電插頭，而圖中綠色部分的 V2新版本依賴邏輯 ，則是歐洲地區的圓孔牆面插座，那麼如何讓國標的扁口插頭能用上歐標的圓孔插座呢？關鍵就是那個插頭轉換器（ Adapter ）。

另類心機：屏蔽開源協議傳染

大家可以回想下，曾經是否也有過從 github 上“ 借鑑 ”一些代碼放進了自己的項目中，然後簡單修改為符合自己訴求的邏輯，便當做是自研代碼去正常使用了？不知道你是否有關注過你所拷貝的代碼所對應的 開源協議 呢？要小心啦、這個看似平常的操作，也許會給項目 埋下致命隱患 ！

為什麼説的這麼危言聳聽呢？因為有一些不太友好的開源協議（比如 GPL 協議），會要求使用了其代碼的項目 如果商用就必須要開源其全部源碼 ！而對於很多軟件公司而言，源碼便是公司的核心資產，是公司最為核心的競爭力，將源碼開源無異於是要了老闆和公司的命。也許有人會對此很不屑，大家都這麼幹，似乎並沒有發現有人來追責呢？有個詞叫做“ 樹大招風 ”，只要你的產品做的夠大，就一定會被盯上 —— 你品，你細品。在當前知識版權保護越來越強的情況下，我們還是應該關注並提前做好應對這種危機出現的可能，避免埋下隱患。

這種情況下，可以基於 Adapter 的機制，實現棄卒保車的效果。即構建一個適配層，然後僅將適配層進行開源，而核心的模塊代碼中，則通過接口調用的方式使用適配層即可，這樣避免了核心模塊代碼被開源協議傳染。由於核心模塊中並沒有集成被二次改動後的開源源碼，所以也不具有開放源碼的義務、而Adapter層沒有任何核心業務邏輯，即使開源對公司、對項目也沒有影響。

基於 Adapter適配層 的方式來切斷開源協議傳染的成功實踐，最典型的莫過於 Android 項目（ AOSP ）了。因為 AOSP 是基於 Linux kernel 內核進行構建的，而 Linux Kernel 使用的是 GPL 協議，那麼按照要求， AOSP 也需要開源其源碼。但是問題來了，如果 AOSP 開源源碼了，勢必導致所有基於 Android 定製的各個硬件廠商底層的設備驅動相關的代碼也都要全部開源，顯然不會有公司願意這麼幹。

為了讓各個公司可以放心的基於 Android 去開發自己的產品， AOSP 將自己的協議搞成了 Apache 開源協議，這樣對產商而言就非常友好了，無需將自己的核心源碼開源。那麼Google是如何做到將本來需要以GPL協議開源的AOSP給變為使用Apache協議開源的呢？其實就是做了一個 Adapter —— 也即 HAL （ Hardware Abstract Layer ，硬件抽象層）。

Adapter是一種理念

關於編碼中的 Adapter ，常規的文檔或者資料中，往往都是指的狹義上的適配器，也就是代 碼class 類維度的 Adapter 。

我們跳出純粹的編碼層面，站到全局系統架構視角去審視的時候，其實 Adapter 在系統架構與編碼設計中是一個比較寬泛的概念。我個人更願意 Adapter 看做是一種 問題解決的思想 、一種 方案設計的理念 。

根據要解決的問題 level 與 範圍 的不同， Adapter 對應的粒度與呈現形態也會有差異。

服務型Adapter

如果是在一個分佈式微服務系統中，消息推送能力可以預見的會提供給很多不同的服務節點去調用，則可以將消息推送能力也封裝為一個對外微服務，業務通過RPC或者HTTP等方式進行遠程調用。

這種是一種相對 High Level 的Adapter抽象使用（但抽象為服務獨立部署後，其實也不僅僅是個Adapter了），廣泛的應用於系統架構層面，是解決系統功能複用、業務解耦的一種有效手段。

在我此前的一篇文章中，介紹了一個構建通用在線文檔預覽服務的實際案例，裏面對“預覽編輯服務”的定位就是一個典型的服務型Adapter，如下圖所示。通過預覽編輯服務這個Adapter，將文檔預覽能力所涉及的後端對接 OnlyOffice 或者對接 kkFileView 等細節邏輯給屏蔽掉，業務服務通過Adapter進行調用，大大簡化了業務的使用複雜度，也保持了業務模塊與文檔預覽服務內部模塊之間的耦合。

服務型Adapter着眼解決的是系統進程層面的適配與統一封裝，自身既是一個Adapter，又是一個獨立的服務，封裝內部細節差異化的實現，保證其它進程服務相對簡單的調用邏輯。

依賴庫型Adapter

在一些中小型項目中，會有若干個業務模塊中會用到消息發送的能力，但是整體體量與業務規劃層面而言，卻也無需單獨部署一個專門的消息推送服務進程，這種情況下，可以將其封裝為一個依賴庫，比如 JAVA 中的一個jar包，或者 C++ 中的一個so庫文件，亦或是 C# 中的dll庫文件。這樣各個業務模塊可以集成此庫文件，直接進行API調用即可。

此種類型的Adapter實現，在很多的框架中非常常見。比如在JAVA中的 SpringBoot 中的日誌框架，底層可以選擇是使用 logback ，也可以選擇切換到 log4j 。

代碼類Adapter

在單個項目模塊中，我們為了保持業務邏輯的清晰與獨立，也會通過 Adapter類 的方式，來解耦具體的業務邏輯。比如這裏的消息推送服務，如果僅當前模塊需要使用，則可以創建一個獨立的Adapter類，提供接口供其他類調用，在 Adapter類 中完成具體邏輯的封裝實現。

還是以前面舉的告警通知消息發送的例子來説明，使用 Adapter 方式隔離消息通道與業務邏輯的實現UML圖如下：

代碼類的 Adapter 在實際項目中使用的場景非常的廣泛，是用於屏蔽代碼底層差異化邏輯的不二選擇。在總結各種實際使用場景與優秀實踐的基礎上，演進為23種設計模式之一的 適配器模式 。

下面我們一起聊一聊適配器模式。

Adapter是一種設計模式

所謂 設計模式 ，便是將常規代碼編碼中常遇到的一些場景的處理方式進行了總結與抽象，固化成一個 優秀實踐範例模板 ，使其整體實現更符合 設計原則 的要求。也就是説：設計模式並非是憑空捏造的，其實就是 來源於常規的編碼實踐總結 。

按照通俗意義上對代碼設計模式的理解，適配器模式也可以分為2種形式，即 類適配器模式 與 對象適配器模式 。

下面分別闡述下。

類適配器模式

類適配器模式整體非常的簡單，涉及的角色也很少。類適配器模式中， Adapter 與被適配的 Adaptee 之間，通過繼承的方式來實現，其 UML 圖如下所示。

主要角色説明如下：

Adaptee：原始被適配的類，即不符合訴求需要由Adapter進行適配的 原始接口 。
Adapter：適配器本身，也是 類適配器模式的核心 ，用於將Adaptee適配為目標的Target。
Target：期待獲取到的目標結果。也即Adaptee經由Adapter適配後得到的統一的 目標接口 。

還是以前面的告警通知發送的場景為例，我們按照聚合的方式，演示下對應的Adapter實現邏輯。

@Service
public class MsgSendAdapter extends SmsSender implements IMsgSender {
    @Override
    public void send(AlarmDetail detail) {
        // detail轉SMS請求體的邏輯
        SmsContent sms = convertToSmsContent(detail);
        super.sendSms(sms);
    }
}

上述代碼中， MsgSendAdapter 繼承了 SmsSender 類並且實現了 IMsgSender 接口，將父類 SmsSender 中的 sendSms 接口轉換為了 IMsgSender 接口提供的目標接口 send() ，業務可以調用 IMsgSender.send() 接口，實現對 SmsSender.sendSms() 邏輯的調用。

對象適配器模式

對象適配器模式與類適配器模式類似，區別點在於 Adapter 與被適配的 Adaptee 之間非繼承關係，而是對象組合關係。其 UML 圖如下：

按照對象適配器的設計思路，其代碼可以如下方式來實現：

@Service
public class MsgSendAdapter implements IMsgSender {
    @Autowired
    private SmsSender smsSender;

    @Override
    public void send(AlarmDetail detail) {
        // detail轉SMS請求體的邏輯
        SmsContent sms = convertToSmsContent(detail);
        smsSender.sendSms(sms);
    }
}

上述代碼中， MsgSendAdapter 類中以組合的方式持有 SmsSender 對象（ Adaptee ），相比較類適配器的繼承邏輯， 靈活性更高 ，所以對象適配器要更加的靈活與實用（其實在架構設計領域也一直有一種觀點叫“ 組合優於繼承 ”，因為繼承打破了面向對象的封裝）。

總結回顧

好啦，關於 Adapter 相關的討論與個人的理解，這裏就給大家分享到這裏。 Adapter 不僅是一個簡單的具體實現類，也不僅僅是23種設計模式之一，更是一種問題解決的思想、一種方案設計的理念。

關於本篇文檔中的內容，不知道屏幕前的各位小夥伴是否在項目中有使用過Adapter或者Adapter模式來幫助自己實現某些功能呢？是否對Adapter還有一些別的獨到見解呢？歡迎評論區留言一起交流下。

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請 點贊 + 關注 讓我感受到您的支持。也可以關注下我的公眾號【架構悟道】，獲取更及時的更新。

期待與你一起探討，一起成長為更好的自己。

「其他文章」