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