🎯 什麼情境該想到我
當你「面對一個由很多類別組成、關係複雜的子系統，客戶端每次都要認識一堆內部物件、照正確順序呼叫才能完成事情」的時候。你想給他們一個簡單的高階入口，把複雜藏在後面。
⚙️ 怎麼用（步驟 / 公式）
意圖：為子系統中的一組介面提供一個統一的、更高階的介面，讓子系統更容易使用。
主要參與者 / 結構：
- Facade（外觀）：知道哪些子系統類別負責哪些請求，把客戶端的請求轉發／協調給適當的子系統物件。
- 子系統類別（Subsystem classes）：實作真正的功能，處理 Facade 交辦的工作；它們不認識 Facade。
- Client：透過 Facade 使用子系統，而非直接接觸內部類別。
做法要點：
- 找出客戶端最常需要的幾條使用流程。
- 建立 Facade 類別，把這些流程封裝成少數幾個簡單方法。
- Facade 方法內部負責協調、依序呼叫各子系統物件。
- 讓客戶端只依賴 Facade，鬆綁它與子系統之間的耦合。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 外觀是「提供方便」而非「封鎖」：不應阻止進階使用者在需要時繞過 Facade 直接使用子系統類別。
- 小心 Facade 膨脹成無所不包的「上帝物件」，把整個系統的邏輯都吸進去。
- 若子系統本來就單純、客戶端也不多，硬加一層外觀只是多餘的間接。
- 外觀降低耦合、但不減少子系統的複雜度本身。
🔗 相關工具
- 配接器模式 Adapter（配接器把單一物件轉成特定既有介面；外觀是為一整組子系統定義一個全新的簡化介面）
- 代理模式 Proxy（代理與真實物件同介面以控制存取；外觀刻意提供不同的、更高階的介面）
- 工具-針對介面編程（客戶端改為依賴 Facade 這個穩定入口）
- 工具-封裝變化點（把子系統的內部結構變動隔在 Facade 後面）
- 設計模式