Head First 設計模式 —— 07. 介面卡模式
阿新 • • 發佈:2021-01-10
#### 思考題
你能想到真實世界中,還有哪些介面卡的例子? `P236`
- HDMI 轉 VGA 轉換器
- Type-C 轉 3.5mm 線
#### 介面卡模式解析
客戶使用介面卡的過程: `P241`
1. 客戶通過目標介面呼叫介面卡的方法對介面卡發出請求
2. 介面卡使用被適配者介面把請求轉換成被適配者的一個或多個呼叫介面
3. 客戶接收到呼叫的結果,但並未察覺這一切是介面卡在起轉換作用(**客戶和被適配者是解耦的,一個不知道另一個**)
#### 思考題
如果我們也需要一個將鴨子轉換成火雞的介面卡,我們稱它為 `DuckAdapter`。請寫下這個類。你如何處理飛行方法(畢竟我們知道鴨子飛得比火雞遠)? `P242`
```java
public class DuckAdapter implements Turkey {
Duck duck;
int count = 0;
public DuckAdapter(Duck duck) {
this.duck = duck;
}
public void gobble() {
duck.quack();
}
public void fly() {
++ count;
if(count == 5) {
count = 0;
duck.fly();
} else {
System.out.println("I'm preparing to fly.");
}
// 答案用的是隨機數取模的方法,平均下來每呼叫5次飛一下
}
}
```
#### 介面卡模式
將一個類的介面,轉換成客戶期望的另一個介面。介面卡讓原本介面不相容的類可以合作無間。 `P243`
![介面卡模式](https://github.com/idealism-xxm/reading-notes/raw/master/head-first-design-patterns/img/07.%20%E9%80%82%E9%85%8D%E5%99%A8%E6%A8%A1%E5%BC%8F.png)
##### 特點
- 讓客戶從實現的介面解耦 `P243`
- 使用物件組合,以修改的介面包裝被適配者 `P243`
- 把客戶和介面繫結起來,而不是和實現繫結起來 `P243`
#### 思考題
物件介面卡(使用組合)和類介面卡(使用繼承)使用兩種不同的適配方法。這兩種實現的差異如何影響介面卡的彈性? `P244`
##### 物件介面卡
- 更具有彈性,不僅可以適配某個類,還可以適配其任何子類 `P247`
- 需要一個被適配者的物件,但可動態變更被適配者
- 難以覆蓋被適配者的行為,只能通過繼承的方式實現
- 只暴露目標介面的行為
##### 類介面卡
- 只能適配特定一個類,但不需要重新實現整個被適配者 `P247`
- 本身就是一個被適配者的物件,但不能動態變更被適配者
- 便於直接在介面卡內覆蓋被適配者的行為
- 不僅暴露目標介面的行為,也暴露被適配者的行為
#### 思考題
某些交流電介面卡所做的事情不只是改變介面,它們還加了一些其他的特性,例如:電湧保護、指示燈、警報聲等。
如果要你實現這類特性,你要使用什麼模式? `P251`
- 裝飾器模式
#### 所思所想
- 介面卡模式也比較常使用,即使沒看過設計模式,憑藉自己的經驗也能寫出來,主要目的就是適配不相容的介面。有一次為了在相容原有特化搜尋介面的基礎上,增加一個定製化搜尋介面,保證一段時間內兩個介面可並存呼叫,並將一部分特化搜尋介面的流量切到定製化搜尋介面上,同時又要保證介面呼叫方無感知,就寫了一個介面卡,將特化搜尋引數轉換成定製化搜尋的引數,並實現部分流量且切入定製化搜尋介面。
> 本文首發於公眾號:滿賦諸機([點選檢視原文](https://mp.weixin.qq.com/s/Wv94Gj-HdlYQBOYGFFtk5g)) 開源在 GitHub :[reading-notes/head-first-design-patterns](https://github.com/idealism-xxm/reading-notes/tree/master/head-first-design-patterns)
![](https://user-images.githubusercontent.com/16055078/103480735-02019200-4e11-11eb-91a2-70a687781