作者：小傅哥
部落格：https://bugstack.cn
沉澱、分享、成長，讓自己和他人都能有所收穫！?
一、前言
擦屁屁紙80%的面積都是保護手的！
工作到3年左右很大一部分程式設計師都想提升自己的技術棧，開始嘗試去閱讀一些原始碼，例如Spring、Mybaits、Dubbo等，但讀著讀著發現越來越難懂，一會從這過來一會跑到那去。甚至懷疑自己技術太差，慢慢也就不願意再觸碰這部分知識。
而這主要的原因是一個框架隨著時間的發展，它的複雜程度是越來越高的，從最開始只有一個非常核心的點到最後開枝散葉。這就像你自己開發的業務程式碼或者某個元件一樣，最開始的那部分核心程式碼也許只能佔到20%，而其他大部分程式碼都是為了保證核心流程能正常執行的。所以這也是你讀原始碼費勁的一部分原因。
框架中用到了設計模式嗎？
框架中不僅用到設計模式還用了很多，而且有些時候根本不是一個模式的單獨使用，而是多種設計模式的綜合運用。與大部分小夥伴平時開發的CRUD可就不一樣了，如果都是if語句從上到下，也就算得不上什麼框架了。就像你到Spring的原始碼中搜關鍵字Adapter，就會出現很多實現類，例如；UserCredentialsDataSourceAdapter。而這種設計模式就是我們本文要介紹的介面卡模式。
介面卡在生活裡隨處可見
如果提到在日常生活中就很多介面卡的存在你會想到什麼？在沒有看後文之前可以先思考下。
二、開發環境
- JDK 1.8
- Idea + Maven
- 涉及工程三個，可以通過關注公眾號：
bugstack蟲洞棧，回覆原始碼下載獲取(開啟獲取的連結，找到序號18)
| 工程 | 描述 |
|---|---|
| itstack-demo-design-6-00 | 場景模擬工程；模擬多個MQ訊息體 |
| itstack-demo-design-6-01 | 使用一坨程式碼實現業務需求 |
| itstack-demo-design-6-02 | 通過設計模式優化改造程式碼，產生對比性從而學習 |
三、介面卡模式介紹
介面卡模式的主要作用就是把原本不相容的介面，通過適配修改做到統一。使得使用者方便使用，就像我們提到的萬能充、資料線、MAC筆記本的轉換頭、出國旅遊買個插座等等，他們都是為了適配各種不同的口，做的相容。。
除了我們生活中出現的各種適配的場景，那麼在業務開發中呢？
在業務開發中我們會經常的需要做不同介面的相容，尤其是中臺服務，中臺需要把各個業務線的各種型別服務做統一包裝，再對外提供介面進行使用。而這在我們平常的開發中也是非常常見的。
四、案例場景模擬
隨著公司的業務的不斷髮展，當基礎的系統逐步成型以後。業務運營就需要開始做使用者的拉新和促活，從而保障DAU的增速以及最終ROI轉換。
而這時候就會需要做一些營銷系統，大部分常見的都是裂變、拉客，例如；你邀請一個使用者開戶、或者邀請一個使用者下單，那麼平臺就會給你返利，多邀多得。同時隨著拉新的量越來越多開始設定每月下單都會給首單獎勵，等等，各種營銷場景。
那麼這個時候做這樣一個系統就會接收各種各樣的MQ訊息或者介面，如果一個個的去開發，就會耗費很大的成本，同時對於後期的擴充也有一定的難度。此時就會希望有一個系統可以配置一下就把外部的MQ接入進行，這些MQ就像上面提到的可能是一些註冊開戶訊息、商品下單訊息等等。
而介面卡的思想方式也恰恰可以運用到這裡，並且我想強調一下，介面卡不只是可以適配介面往往還可以適配一些屬性資訊。
1. 場景模擬工程
itstack-demo-design-6-00
└── src
└── main
└── java
└── org.itstack.demo.design
├── mq
│ ├── create_account.java
│ ├── OrderMq.java
│ └── POPOrderDelivered.java
└── service
├── OrderServicejava
└── POPOrderService.java
- 這裡模擬了三個不同型別的MQ訊息，而在訊息體中都有一些必要的欄位，比如；使用者ID、時間、業務ID，但是每個MQ的欄位屬性並不一樣。就像使用者ID在不同的MQ裡也有不同的欄位：uId、userId等。
- 同時還提供了兩個不同型別的介面，一個用於查詢內部訂單訂單下單數量，一個用於查詢第三方是否首單。
- 後面會把這些不同型別的MQ和介面做適配相容。
2. 場景簡述
1.1 註冊開戶MQ
public class create_account {
private String number; // 開戶編號
private String address; // 開戶地
private Date accountDate; // 開戶時間
private String desc; // 開戶描述
// ... get/set
}
1.2 內部訂單MQ
public class OrderMq {
private String uid; // 使用者ID
private String sku; // 商品
private String orderId; // 訂單ID
private Date createOrderTime; // 下單時間
// ... get/set
}
1.3 第三方訂單MQ
public class POPOrderDelivered {
private String uId; // 使用者ID
private String orderId; // 訂單號
private Date orderTime; // 下單時間
private Date sku; // 商品
private Date skuName; // 商品名稱
private BigDecimal decimal; // 金額
// ... get/set
}
1.4 查詢使用者內部下單數量介面
public class OrderService {
private Logger logger = LoggerFactory.getLogger(POPOrderService.class);
public long queryUserOrderCount(String userId){
logger.info("自營商家，查詢使用者的訂單是否為首單：{}", userId);
return 10L;
}
}
1.5 查詢使用者第三方下單首單介面
public class POPOrderService {
private Logger logger = LoggerFactory.getLogger(POPOrderService.class);
public boolean isFirstOrder(String uId) {
logger.info("POP商家，查詢使用者的訂單是否為首單：{}", uId);
return true;
}
}
- 以上這幾項就是不同的MQ以及不同的介面的一個體現，後面我們將使用這樣的MQ訊息和介面，給它們做相應的適配。
五、用一坨坨程式碼實現
其實大部分時候接MQ訊息都是建立一個類用於消費，通過轉換他的MQ訊息屬性給自己的方法。
我們接下來也是先體現一下這種方式的實現模擬，但是這樣的實現有一個很大的問題就是，當MQ訊息越來越多後，甚至幾十幾百以後，你作為中颱要怎麼優化呢？
1. 工程結構
itstack-demo-design-6-01
└── src
└── main
└── java
└── org.itstack.demo.design
└── create_accountMqService.java
└── OrderMqService.java
└── POPOrderDeliveredService.java
- 目前需要接收三個MQ訊息，所有就有了三個對應的類，和我們平時的程式碼幾乎一樣。如果你的MQ量不多，這樣的寫法也沒什麼問題，但是隨著數量的增加，就需要考慮用一些設計模式來解決。
2. Mq接收訊息實現
public class create_accountMqService {
public void onMessage(String message) {
create_account mq = JSON.parseObject(message, create_account.class);
mq.getNumber();
mq.getAccountDate();
// ... 處理自己的業務
}
}
- 三組MQ的訊息都是一樣模擬使用，就不一一展示了。可以獲取原始碼後學習。
六、介面卡模式重構程式碼
接下來使用介面卡模式來進行程式碼優化，也算是一次很小的重構。
介面卡模式要解決的主要問題就是多種差異化型別的介面做統一輸出，這在我們學習工廠方法模式中也有所提到不同種類的獎品處理，其實那也是介面卡的應用。
在本文中我們還會再另外體現出一個多種MQ接收，使用MQ的場景。來把不同型別的訊息做統一的處理，便於減少後續對MQ接收。
在這裡如果你之前沒要開發過接收MQ訊息，可能聽上去會有些不理解這樣的場景。對此，我個人建議先了解下MQ。另外就算不了解也沒關係，不會影響對思路的體會。
再者，本文所展示的MQ相容的核心部分，也就是處理適配不同的型別欄位。而如果我們接收MQ後，在配置不同的消費類時，如果不希望一個個開發類，那麼可以使用代理類的方式進行處理。
1. 工程結構
itstack-demo-design-6-02
└── src
└── main
└── java
└── org.itstack.demo.design
├── impl
│ ├── InsideOrderService.java
│ └── POPOrderAdapterServiceImpl.java
├── MQAdapter,java
├── OrderAdapterService,java
└── RebateInfo,java
介面卡模型結構
- 這裡包括了兩個型別的適配；介面適配、MQ適配。之所以不只是模擬介面適配，因為很多時候大家都很常見了，所以把適配的思想換一下到MQ訊息體上，增加大家多設計模式的認知。
- 先是做MQ適配，接收各種各樣的MQ訊息。當業務發展的很快，需要對下單使用者首單才給獎勵，在這樣的場景下再增加對介面的適配操作。
2. 程式碼實現(MQ訊息適配)
2.1 統一的MQ訊息體
public class RebateInfo {
private String userId; // 使用者ID
private String bizId; // 業務ID
private Date bizTime; // 業務時間
private String desc; // 業務描述
// ... get/set
}
- MQ訊息中會有多種多樣的型別屬性，雖然他們都有同樣的值提供給使用方，但是如果都這樣接入那麼當MQ訊息特別多時候就會很麻煩。
- 所以在這個案例中我們定義了通用的MQ訊息體，後續把所有接入進來的訊息進行統一的處理。
2.2 MQ訊息體適配類
public class MQAdapter {
public static RebateInfo filter(String strJson, Map<String, String> link) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
return filter(JSON.parseObject(strJson, Map.class), link);
}
public static RebateInfo filter(Map obj, Map<String, String> link) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
RebateInfo rebateInfo = new RebateInfo();
for (String key : link.keySet()) {
Object val = obj.get(link.get(key));
RebateInfo.class.getMethod("set" + key.substring(0, 1).toUpperCase() + key.substring(1), String.class).invoke(rebateInfo, val.toString());
}
return rebateInfo;
}
}
- 這個類裡的方法非常重要，主要用於把不同型別MQ種的各種屬性，對映成我們需要的屬性並返回。就像一個屬性中有
使用者ID;uId，對映到我們需要的；userId，做統一處理。 - 而在這個處理過程中需要把對映管理傳遞給
Map<String, String> link，也就是準確的描述了，當前MQ中某個屬性名稱，對映為我們的某個屬性名稱。 - 最終因為我們接收到的
mq訊息基本都是json格式，可以轉換為MAP結構。最後使用反射呼叫的方式給我們的型別賦值。
2.3 測試適配類
2.3.1 編寫單元測試類
@Test
public void test_MQAdapter() throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
create_account create_account = new create_account();
create_account.setNumber("100001");
create_account.setAddress("河北省.廊坊市.廣陽區.大學裡職業技術學院");
create_account.setAccountDate(new Date());
create_account.setDesc("在校開戶");
HashMap<String, String> link01 = new HashMap<String, String>();
link01.put("userId", "number");
link01.put("bizId", "number");
link01.put("bizTime", "accountDate");
link01.put("desc", "desc");
RebateInfo rebateInfo01 = MQAdapter.filter(create_account.toString(), link01);
System.out.println("mq.create_account(適配前)" + create_account.toString());
System.out.println("mq.create_account(適配後)" + JSON.toJSONString(rebateInfo01));
System.out.println("");
OrderMq orderMq = new OrderMq();
orderMq.setUid("100001");
orderMq.setSku("10928092093111123");
orderMq.setOrderId("100000890193847111");
orderMq.setCreateOrderTime(new Date());
HashMap<String, String> link02 = new HashMap<String, String>();
link02.put("userId", "uid");
link02.put("bizId", "orderId");
link02.put("bizTime", "createOrderTime");
RebateInfo rebateInfo02 = MQAdapter.filter(orderMq.toString(), link02);
System.out.println("mq.orderMq(適配前)" + orderMq.toString());
System.out.println("mq.orderMq(適配後)" + JSON.toJSONString(rebateInfo02));
}
- 在這裡我們分別模擬傳入了兩個不同的MQ訊息，並設定欄位的對映關係。
- 等真的業務場景開發中，就可以配這種對映配置關係交給配置檔案或者資料庫後臺配置，減少編碼。
2.3.2 測試結果
mq.create_account(適配前){"accountDate":1591024816000,"address":"河北省.廊坊市.廣陽區.大學裡職業技術學院","desc":"在校開戶","number":"100001"}
mq.create_account(適配後){"bizId":"100001","bizTime":1591077840669,"desc":"在校開戶","userId":"100001"}
mq.orderMq(適配前){"createOrderTime":1591024816000,"orderId":"100000890193847111","sku":"10928092093111123","uid":"100001"}
mq.orderMq(適配後){"bizId":"100000890193847111","bizTime":1591077840669,"userId":"100001"}
Process finished with exit code 0
- 從上面可以看到，同樣的欄位值在做了適配前後分別有統一的欄位屬性，進行處理。這樣業務開發中也就非常簡單了。
- 另外有一個非常重要的地方，在實際業務開發中，除了反射的使用外，還可以加入代理類把對映的配置交給它。這樣就可以不需要每一個mq都手動建立類了。
3. 程式碼實現(介面使用適配)
就像我們前面提到隨著業務的發展，營銷活動本身要修改，不能只是接了MQ就發獎勵。因為此時已經拉新的越來越多了，需要做一些限制。
因為增加了只有首單使用者才給獎勵，也就是你一年或者新人或者一個月的第一單才給你獎勵，而不是你之前每一次下單都給獎勵。
那麼就需要對此種方式進行限制，而此時MQ中並沒有判斷首單的屬性。只能通過介面進行查詢，而拿到的介面如下；
| 介面 | 描述 |
|---|---|
| org.itstack.demo.design.service.OrderService.queryUserOrderCount(String userId) | 出參long，查詢訂單數量 |
| org.itstack.demo.design.service.OrderService.POPOrderService.isFirstOrder(String uId) | 出參boolean，判斷是否首單 |
- 兩個介面的判斷邏輯和使用方式都不同，不同的介面提供方，也有不同的出參。一個是直接判斷是否首單，另外一個需要根據訂單數量判斷。
- 因此這裡需要使用到介面卡的模式來實現，當然如果你去編寫if語句也是可以實現的，但是我們經常會提到這樣的程式碼很難維護。
3.1 定義統一適配介面
public interface OrderAdapterService {
boolean isFirst(String uId);
}
- 後面的實現類都需要完成此介面，並把具體的邏輯包裝到指定的類中，滿足單一職責。
3.2 分別實現兩個不同的介面
內部商品介面
public class InsideOrderService implements OrderAdapterService {
private OrderService orderService = new OrderService();
public boolean isFirst(String uId) {
return orderService.queryUserOrderCount(uId) <= 1;
}
}
第三方商品介面
public class POPOrderAdapterServiceImpl implements OrderAdapterService {
private POPOrderService popOrderService = new POPOrderService();
public boolean isFirst(String uId) {
return popOrderService.isFirstOrder(uId);
}
}
- 在這兩個介面中都實現了各自的判斷方式，尤其像是提供訂單數量的介面，需要自己判斷當前接到mq時訂單數量是否
<= 1，以此判斷是否為首單。
3.3 測試適配類
3.3.1 編寫單元測試類
@Test
public void test_itfAdapter() {
OrderAdapterService popOrderAdapterService = new POPOrderAdapterServiceImpl();
System.out.println("判斷首單，介面適配(POP)：" + popOrderAdapterService.isFirst("100001"));
OrderAdapterService insideOrderService = new InsideOrderService();
System.out.println("判斷首單，介面適配(自營)：" + insideOrderService.isFirst("100001"));
}
3.3.2 測試結果
23:25:47.076 [main] INFO o.i.d.design.service.POPOrderService - POP商家，查詢使用者的訂單是否為首單：100001
判斷首單，介面適配(POP)：true
23:25:47.079 [main] INFO o.i.d.design.service.POPOrderService - 自營商家，查詢使用者的訂單是否為首單：100001
判斷首單，介面適配(自營)：false
Process finished with exit code 0
- 從測試結果上來看，此時已經的介面已經做了統一的包裝，外部使用時候就不需要關心內部的具體邏輯了。而且在呼叫的時候只需要傳入統一的引數即可，這樣就滿足了適配的作用。
七、總結
- 從上文可以看到不使用介面卡模式這些功能同樣可以實現，但是使用了介面卡模式就可以讓程式碼：乾淨整潔易於維護、減少大量重複的判斷和使用、讓程式碼更加易於維護和擴充。
- 尤其是我們對MQ這樣的多種訊息體中不同屬性同類的值，進行適配再加上代理類，就可以使用簡單的配置方式接入對方提供的MQ訊息，而不需要大量重複的開發。非常利於擴充。
- 設計模式的學習學習過程可能會在一些章節中涉及到其他設計模式的體現，只不過不會重點講解，避免喧賓奪主。但在實際的使用中，往往很多設計模式是綜合使用的，並不會單一出現。