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

大家好，又見面了。

不知道下面這玩意大家有沒有見過或者使用過？這是一個插座轉換器。我們都知道日常使用的是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還有一些別的獨到見解呢？