重新整理Facade Pattern

July 31 21:10~22:24

圖片來源：GoF第185頁。

 

昨天整理了State模式（請參考《重新整理State Pattern》），打鐵趁熱，今天繼續來整理Facade模式。昨天已經示範過如何step by step，從描述form開始、接著尋找force、定義problem、釐清context，最後用新的格式來介紹State模式。今天省略「推理過程」，直接看結果。

***

Name：Facade

Context：當一個系統越來越龐大的時候，如果沒有好好規劃系統結構，整個系統內部物件之間的關聯性很容易變得過於複雜，最後導致牽一髮而動全身；除了影響開發速度，也很容易導致不預期的程式錯誤。一種常見的結構化方式是將系統依據功能劃分為若干個子系統，子系統內部的物件允許較緊密的關聯，而子系統之間則應該要儘量降低其相依性。

Problem：如何使用子系統？

Force：

• 一個子系統可能會有很多個客戶端使用它，我們不希望子系統內部的改變，即使是非常輕微的異動，將會導致客戶端需要跟著改變。
• 如果子系統的使用方式過於複雜，客戶端會被迫必須了解很多子系統的細節，這樣將會增加客戶端的學習曲線、提高客戶端與子系統內部的相依性，甚至可能會導致客戶端拒絕使用子系統而走向自行開發的道路。
  

Solution：提供一個存取子系統內部各項服務的單一介面，讓子系統變得更容易使用，並且可隔離客戶端程式對子系統內部元件的相依性。

***

以下兩張投影片是Teddy上課時所舉的Facade例子。

***

結束，就這麼簡單。

等一下，結束之前Teddy補充說明一點。鄉民們用C++、Java、C#這些語言寫程式的時候，語言本身有提供namespace或是package這種用來區分子系統或是模組的方法。但是，不知道鄉民們有沒有一種感覺，就算是設計好了namespace或是package，為什麼客戶端的程式還是跟子系統內部的物件有著很高的相依性（耦合度）呢？如果有這種症況，有可能就是鄉民們的子系統「沒有門禁」，導致「門戶洞開」，「敵人」長驅直入。

這時候，考慮幫鄉民們的子系統設計一個Facade，也許可以減輕這個症狀。

***

友藏內心獨白：現在進度，23分之2。應該高興嗎？