要想正確理解設計模式,首先必須明確它是為了解決什么問題而提出來的。
設計模式學習筆記
——Shulin
轉載請注明出處:http://blog.csdn.net/zhshulin
門面模式是對象的結構模式,外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的接口,使得子系統更易于使用。
為子系統提供一個高層次的接口,使子系統易于使用。
適用性:
1)當你要為一個復雜子系統提供一個簡單接口時。子系統往往因為不斷演化而變得越來越復雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具可重用性,也更容易對子系統進行定制,但這也給那些不需要定制子系統的用戶帶來一些使用上的困難。Facade可以提供一個簡單的缺省視圖,這一視圖對大多數用戶來說已經足夠,而那些需要更多的可定制性的用戶可以越過facade層。(簡單點說門面就是提供一些基礎服務滿足大多數用戶,而有特殊需求的可以越過門面,直接和系統進行交互)
2)客戶程序與抽象類的實現部分之間存在著很大的依賴性。引入facade將這個子系統與客戶以及其他的子系統分離,可以提高子系統的獨立性和可移植性。
3)當你需要構建一個層次結構的子系統時,使用facade模式定義子系統中每層的入口點。如果子系統之間是相互依賴的,你可以讓它們僅通過facade進行通訊,從而簡化了它們之間的依賴關系。
門面模式是對象的結構模式。門面模式沒有一個一般化的類圖描述,下圖演示了一個門面模式的示意性對象圖:
門面(Facade)角色:客戶端可以調用這個角色的方法。此角色知曉相關的(一個或者多個)子系統的功能和責任。在正常情況下,本角色會將所有從客戶 端發來的請求委派到相應的子系統去。
子系統(subsystem)角色:可以同時有一個或者多個子系統。每一個子系統都不是一個單獨的類,而是一個類的集合。每一個子系統都可以被客戶端直接 調用,或者被門面角色調用。子系統并不知道門面的存在,對于子系統而言,門面僅僅是另外一個客戶端而已。
現代的軟件系統都是比較復雜的,設計師處理復雜系統的一個常見方法便是將其“分而治之”,把一個系統劃分為幾個較小的子系統。
醫院的例子:如果把醫院作為一個子系統,按照部門職能,這個系統可以劃分為掛號、門診、劃價、化驗、收費、取藥等。看病的病人要與這些部門打交道,就如同一個子系統的客戶端與一個子系統的各個類打交道一樣,不是一件容易的事情。
首先病人必須先掛號,然后門診。如果醫生要求化驗,病人必須首先劃價,然后繳費,才可以到化驗部門做化驗。化驗后再回到門診室。
解決這種不便引進門面模式,醫院可以設置一個接待員的位置,由接待員負責代為掛號、劃價、繳費、取藥等。這個接待員就是門面模式的體現,病人只接觸接待員,由接待員與各個部門打交道。
各個具體業務類:
[java] view plain copy PRint?這個例子在現實中有一個不足之處就是門診應該讓客戶端直接和門診類打交道,其他的都可以通過接待中心(Facade)來進行,方便病人就診。但是不影響理解門面模式的設計思想,反而更易于理解其思想。門面模式就是取出子系統中各類的基本功能來滿足大部分用戶的需求,如果有特殊需求,可以和具體類直接交互。
? 松散耦合
時客戶端與子系統解耦,讓子系統內部的模塊能更容易擴展和維護。
? 簡單易用
客戶端只需要跟門面類交互就可以了。
? 更好劃分訪問層次
有些方法是對系統外的,有些方法是系統內部使用的。把需要暴露給外部的功能集中到 門面中,這樣既方便客戶端使用,也很好地隱藏了內部的細節。
不符合開閉原則。所謂的開閉原則是軟件工程里面一個最基本的原則:對擴展開放,對修改關閉。換句話說,你的系統可以提供新的功能模塊而不必進行修改。
新聞熱點
疑難解答