今天我們開始介紹本書第一個提到的設計模式：Facade 模式。我會介紹什麼是 Facade 模式、它的一些關鍵特徵和它帶來的好處。Let's dive in!

Facade 模式想解決的問題

先給出一個情境吧！

假設你在開發的一項產品的功能 A 中需要用到系統中已經實作過的計算商品日期相關的功能。你不可能把的整套計算日期的流程塞進功能 A 裡，因為它背後涉及的商務邏輯太過複雜，如果要使用它，得跑過四五個流程，而且分別散在好幾個類別中。

這時候，該如何解決這個問題呢？

Facade 模式是怎麼解決的

Facade 模式在這時候就派上用場。

簡單地說

GoF 是如此描述 Facade 模式的：

（Facade 模式）為子系統中的一組介面定義一個統一介面。Facade 模式定義了一個更高層的介面，使子系統更加容易使用。

意思就是，當客戶 (Client) 只需要使用某個子系統中的功能時，我們可以新增一個介面，使客戶透過這個介面 (Facade) 與子系統做交流。

注意到，這種方法在只使用系統的一部分功能，或是以特殊方式與系統交流時才有用，如果客戶需要使用到系統的所有功能，那麼無須對設計進行改進。

回頭看上述的例子

所以，在上述的例子，我們可以實作一個 CommodityDateTimeFacade 類別（亂取的），這個 Facade 使用與計算商品日期相關的底層相關的系統，重新實作出我們需要的新函數。

這樣子我們只要使用這個類別就能使用子系統中的計算商品日期的功能了！

關鍵特徵

以下是 Facade 模式的關鍵特徵：

UML 圖可以這樣理解：

它有什麼其他好處？

1. 減少客戶處理的物件數量

Facade 建立出了簡單的介面後，可以降低客戶處理處理物件的數量。舉例來說，客戶想拿取資料，他可能需要做

• 透過 Database 物件呼叫資料庫
• 拿出 Model 物件
• 透過查詢 Model 物件，拿出 Element 物件

我們可以透過 Facade 將上述三個步驟放進 Facade 中實作，那麼客戶就只需要呼叫 Facade 即可。

2. 替舊系統加上新功能

新功能例如：紀錄我們對某特定子系統呼叫的次數。這個需求可以放進 Facade 中實作。

3. 一個封裝層

Facade 可以用來隱藏和封裝系統。它能夠把系統作為自己的私有成員包含進來。這樣子，原系統將會與 Facade 類別關聯起來，而客戶無需知道。

封裝系統的好處有：

• 追蹤系統的使用情況：強制地讓客戶使用系統時都必須經過 Facade，可以容易地監控系統被使用的情況
• 更換系統：當需要切換新的系統時，理想上只需要在一個地方（Facade 類別）修改程式碼即可，降低維護成本

接下來

Facade 模式就先介紹到這裡！下一篇會介紹另一個設計模式 —— Adapter 模式。明天見！