本章主軸#
外觀模式（Facade）是書中介紹的第一個模式，也是許多人已經寫過、只是不知道它的名字的模式。它的核心是：當我們只需要使用某個複雜系統的一部分（或以特定方式使用它），就建立一個新的、簡化的介面當作「外觀」。
GoF 對 Facade 的意圖描述#
為子系統的一組介面提供一個統一的介面。Facade 定義一個高層介面，使該子系統更容易使用。
換句話說，當與某個系統互動的成本太高，就建立一個比原系統更簡單、或更貼合自己需求的介面。
一個實戰啟發：八呎高的手冊#
作者曾接案，同事丟給他「八呎高的 CAD/CAM 手冊」叫他先讀完。可想而知一個小團隊不會讓每個人都把整本讀完——通常會抽籤決定一個人去寫一層封裝介面，其他人透過這層介面工作。
Figure 6-1: 八呎高的手冊 = 一個複雜系統
那層封裝介面，就是 Facade。它定義團隊真正需要的 API，避免每個成員都要學完整個複雜系統。
Figure 6-2: Facade 把客戶端與子系統隔離開
Figure 6-3: Facade 模式的通用結構——對外簡化介面，內部仍呼叫子系統
Facade 的關鍵特性#
| 欄位 | 內容 |
|---|---|
| Intent | 簡化既有系統的使用方式，並定義屬於自己的介面 |
| Problem | 只需用到複雜系統的一部分，或需要以特定方式互動 |
| Solution | Facade 提供新的介面給使用者使用 |
| Consequences | 使用變簡單；但因為 Facade 不完整，部分功能可能無法透過 Facade 使用 |
| Implementation | 定義一個新類別（或數個），對外提供新介面，內部仍呼叫原系統 |
適用的時機#
- 不需要使用複雜系統的全部功能，只需一個子集
- 想要把原系統「封裝」起來
- 想要在使用原系統的同時，加上新的功能
- 寫這個 Facade 的成本，比讓每個人都學原系統、或未來付出的維護成本來得低
Facade 的常見變體#
減少 client 必須面對的物件數量#
- 原本 client 要先打開 Database、取出 Model、再從 Model 拿 Element、最後才能查資料
- 透過
DatabaseFacade，client 一次發問就能拿到所需資訊
Figure 6-4: Facade 減少了 client 需要面對的物件數量
讓單一 Facade 服務多個物件#
若 Facade 是無狀態的，多個物件可共用同一個 Facade 物件。後續第 21 章會用 Singleton 與 Double-Checked Locking 模式說明做法。
在原系統功能之外補充新功能#
例如：在 Facade 內加入呼叫紀錄、計量、權限檢查。原則：不要讓 client 發現自己還得呼叫額外步驟——Facade 自己幫忙。
把整個系統封進 Facade 內部#
把原系統當成 Facade 類別的私有成員，可以：
- 追蹤系統使用情形——所有呼叫都經過 Facade
- 將來抽換系統——只需替換 Facade 中的私有成員，不影響 client
與 CAD/CAM 問題的關聯#
V1 系統是一堆函式庫呼叫，每次查詢都很冗長。Facade 可以讓 V1Slot、V1Hole 等物件透過簡化過的介面呼叫 V1，避免每個衍生類別都要熟記繁瑣的呼叫流程（第 13 章會具體展示）。
本章要記住的事#
- 模式只設定整體做法，不是僵化的模板
- Facade 不只能簡化呼叫，也能：減少物件數、附加新功能、封裝整個系統
- 它的精神：為 client 客製一個更友善的介面，把複雜性藏到背後