l

2013年8月1日 星期四

重新整理Facade Pattern

July 31 21:10~22:24

螢幕快照 2013-07-31 下午9.28.16

圖片來源:GoF第185頁。

 

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

***

Name:Facade

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

Problem:如何使用子系統?

Force:

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

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

***

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

螢幕快照 2013-07-31 下午10.00.17

螢幕快照 2013-07-31 下午10.20.50

***

結束,就這麼簡單。

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

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

***

友藏內心獨白:現在進度,23分之2。應該高興嗎挑眉質疑

7 則留言:

  1. 太棒了~我又進步了,謝謝 Teddy

    回覆刪除
  2. 一天一pattern,再21天就會變成23/23 XD

    回覆刪除
    回覆
    1. 如果每天都寫pattern,圍觀的鄉民可能很快會就散去....XD。

      不是每個人都對pattern有興趣啊...Orz。

      刪除
  3. 唯有 pattern 才是王道,不然只是打字工程師

    回覆刪除
  4. Teddy教主 千秋萬載 一統江湖~

    回覆刪除
  5. "唯有 pattern 才是王道,不然只是打字工程師" <- 這當然不是真的,pattern是有經驗的工程師為了傳遞隱性知識所編纂的型錄,就像任何領域累積的成果一樣,能直接學到別人的經驗是還不錯,可以縮短成長時間,但這並不是成長唯一的路徑,也不一定是最好的路徑。

    回覆刪除