設計模式的解析與活用 - ch6 === # Facade 模式 --- ## Agenda - 認識 Facade 模式 - 問題情境 - Facade 模式的特徵 - Facade 模式的變體 - 問題與討論 --- ## Facade 模式 定義了更高層次的介面，讓子系統變得更容易使用 --- ## 問題情境 - 思路與好處 1. 專案內的使用手冊堆積如山 2. 透過新介面，不用完整摸透內部複雜系統 3. 將客戶與子系統隔離 --- ## 關鍵特徵 - 意圖：簡化原系統使用方式，需定義自己介面 - 問題：只會用複雜系統的子集，或要特別方式存取系統 - 解決方式：在原系統上提供一個新介面 - 參與者：提供簡化介面，讓系統更容易使用 - 效果：除了達到簡易使用，同時也無法使用完整系統功能 - 實作上： - 定義一個或多個所需介面的新類別 - 讓新類別使用原本系統 --- ## Facade 模式概念圖  --- ## 簡化呼叫所需物件數量  [ref: Design Patterns Explained](https://www.oreilly.com/library/view/design-patterns-explained/0201715945/0201715945_ch06lev1sec4.html) [ref: origin book ch6.](https://www.pearsonhighered.com/assets/samplechapter/0/3/2/1/0321247140.pdf ) --- ## 模式提供了通用方法 - 模式只是可以作為起點的藍圖，並非完全原樣照搬 - Facade 模式下可以新增方法，但目的仍是簡化原本流程 --- ## 封裝背後的原因 1. 追蹤系統的使用情況：將對系統的存取都改為使用 Facade，達成監控 2. 改換系統：預期未來會更換系統，將原系統設為 Facade 類別的 private member，期望降低之後轉換的成本 --- ## 小結：Facade 模式適用情境 - 希望封裝或隱藏原系統 - 希望使用原本系統，也想加新功能 - 降低團隊成員學習成本，或維護成本 --- 問題與討論