今天要講的設計模式堪稱人人都會，不是因為它太簡單，而是因為它太常見，它就是 介面卡模式
這個玩意大家應該都認識，它是一個耳機轉接頭
假如你只有一個圓孔插頭的耳機，但是手機的音訊插口是type-c的，這時候你是沒辦法用耳機聽歌的
利用耳機轉接頭，就可以使用圓孔的插頭和type-c插口的手機來聽歌
在我們對接一個三方系統時，假如我們系統的介面規範和三方系統的介面規範不一樣，該怎麼對接
介面規範不一致，導致我們不能和三方系統完成對接，必須修改其中一方的介面規範
但是，不管修改哪一方的介面規範都可能導致系統已有的功能不能正常使用
讓我們發揮想象，把我們系統比作是圓孔耳機，把三方系統比作是type-c插口的手機。我們只需要一個「耳機轉接頭」就可以完成兩個系統的對接，而且不需要修改任何一方的程式碼
這裡的「耳機轉接頭」的作用就是把我們系統的介面規範轉換成三方系統的介面規範，讓兩個系統都不需要修改程式碼就可以完成無縫對接
仔細想想一下，在我們的實際工作中，是不是經常做「耳機轉接頭」這樣的工作
實際上，「耳機轉接頭」就是一個介面卡，這就是一個簡單的「介面卡模式」
系統間的呼叫會用到介面卡模式，程式碼直接的呼叫也會用到介面卡模式
使用場景
在兩個功能間無法完成無縫對接，必須要修改其中一處功能，但是修改工作量較大或者擔心修改完造成已有功能無法使用時，可以考慮使用介面卡模式
介面卡模式的識別方法：「當一個方法的入參是一個物件，而返回值是另一個物件時，這個方法就是一個介面卡模式」
比如，java中的 java.util.Arrays#asList()
這個方法的作用是把一個陣列轉換成list集合。陣列和list屬於兩個不同的類，沒辦法完成無縫轉換
這時候就需要這個方法來進行「適配」，它的入參是一個任意型別的陣列物件，返回值是一個list物件，符合上面我們說的介面卡模式的識別方法，所以這個方法就是一個介面卡模式
實際案例
假如我們有一個介面，需要統計使用者最近購買的商品資訊並返回給前臺
查詢資料庫的方法已經封裝好，返回的資料格式如下
前臺要求返回的資料格式如下
我們先來用程式碼模擬一下從資料庫查詢資料的邏輯
這裡需要一個實體類，用來對應資料庫查詢出來的資料
用程式碼模擬從資料庫查詢出5條資料
再來模擬一下前臺要求的資料格式
這裡需要兩個實體類對應前臺要求的資料格式
用程式碼來模擬一下實際給前臺返回資料的邏輯
從資料庫查詢出來的資料和前臺要求的資料都用程式碼模擬出來了，那麼該怎麼把從資料庫查詢出來的格式轉換成前臺需要的格式？
也就是說要怎麼把List<UserProductInfo>物件轉換成List<UserProductInfoRsp>物件？
修改查詢資料庫的方法邏輯顯然不合適，作為DAO層對所有業務提供通用的查詢資料庫的能力，修改後會導致其他呼叫該方法的業務報錯
修改前臺資料格式也不合適，前臺開發模式是一雲多端的模式，不可能讓所有端的前臺都跟著修改程式碼
所以，該介面卡模式出場啦
我們需要定義一個方法，方法的入參是List<UserProductInfo>，方法的返回值是List<UserProductInfoRsp>，在這個方法中完成兩個物件的轉換
ps：該方法的業務邏輯稍微有點複雜，感興趣的同學可以看一下。不願意看也行，只看方法的入參和返回值也不影響對介面卡模式的理解
這樣我們就用介面卡模式完成了兩個物件的轉換，而且兩方的業務邏輯都不需要修改，堪稱“完美”
總結
介面卡模式又被稱為包裝模式或封裝器模式
當兩個功能間無法完成無縫對接，必須要修改其中一處功能，但是修改工作量較大或者擔心修改完造成已有功能無法使用時，可以考慮使用介面卡模式
「介面卡模式的優點」
- 解耦：介面卡將兩個功能完全解耦，從而達到不需要修改任何一方的原有邏輯的目的
- 提高程式碼複用性：適配的兩方不需要修改任何邏輯，可以更專注自己本身的業務邏輯，對外提供更通用的能力，使程式碼的複用性更好
- 提高系統的擴充套件性：可以通過各種介面卡，對已有的功能或系統進行適配，讓其能適應更多的場景，使自己的功能或系統擴充套件性更高
「介面卡模式的缺點」
- 造成系統結構混亂：過多的使用介面卡，會造成系統過於龐大且混亂不利於系統維護
學會設計模式不是目的，理解設計模式隱含的設計思想才能無往不利
「技術需要沉澱，我們下期再見」
-- 以上內容來自公眾號「赫連小伍」，轉載請註明出處