體系結(jié)構(gòu)課件第十三章外觀模式

第十三章外觀模式

(FacadePattern)—門面模式13.1外觀模式簡介如醫(yī)院的就診的情況（醫(yī)院—子系統(tǒng)，外觀—導(dǎo)醫(yī)）客戶端程序與完成實際業(yè)務(wù)功能的子系統(tǒng)程序之間通信時采用的2種方案:13.1外觀模式簡介（續(xù)）上述A方案的問題在于組件的客戶（即外部接口，或客戶程序）和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化，這種過多的耦合面臨很多變化的挑戰(zhàn)。如何簡化外部客戶程序和系統(tǒng)間的交互接口？如何將外部客戶程序的演化和內(nèi)部子系統(tǒng)的變化之間的依賴相互解耦？為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。——《設(shè)計模式》GoF13.2外觀模式的結(jié)構(gòu)外觀模式是對象的結(jié)構(gòu)模式。外觀模式?jīng)]有一個一般化的類圖描述，下圖演示了一個外觀模式的示意性對象圖:

這種結(jié)構(gòu)不僅體現(xiàn)了類的單一職責(zé)原則，而且也體現(xiàn)了開放/封閉原則。子系統(tǒng)和系統(tǒng)之間是組合關(guān)系，而不是繼承關(guān)系。高層總是相對穩(wěn)定，低層總是相對易變。所以我們應(yīng)該盡量依賴高層抽象，而不是低層細(xì)節(jié)實現(xiàn)。13.2外觀模式的結(jié)構(gòu)（續(xù)）外觀(Facade)角色：客戶端可以調(diào)用這個角色的方法。此角色知曉相關(guān)的(一個或者多個)子系統(tǒng)的功能和責(zé)任。在正常情況下，本角色會將所有從客戶端發(fā)來的請求委派到相應(yīng)的子系統(tǒng)去。子系統(tǒng)(SubSystem)角色：可以同時有一個或者多個子系統(tǒng)。每一個子系統(tǒng)都不是一個單獨的類，而是一個類的集合。每一個子系統(tǒng)都可以被客戶端直接調(diào)用，或者被門面角色調(diào)用。子系統(tǒng)并不知道門面的存在，對于子系統(tǒng)而言，門面僅僅是另外一個客戶端而已。需要注意的2點:外觀類通常是單例類,每個子系統(tǒng)一個外觀類;擴(kuò)展功能不應(yīng)該繼承外觀類,而是在子系統(tǒng)代碼中擴(kuò)展,外觀類只是為對子系統(tǒng)的訪問提供一個集中化的、簡化的渠道。13.3示例保安系統(tǒng)：由兩個錄像機、三個電燈、一個遙感器和一個警報器組成，保安系統(tǒng)的操作人員需要經(jīng)常將這些儀器啟動和關(guān)閉。示例：SecurityClassical示例：SecurityFacade13.4外觀模式的應(yīng)用設(shè)計初期階段有意識的建立三層架構(gòu)，層與層之間建立外觀Facade(層間接口)。開發(fā)階段子系統(tǒng)往往因為不斷的重構(gòu)演化而變得越來越復(fù)雜，大規(guī)模的使用模式會產(chǎn)生很多很小的類,這將使維護(hù)工作變得復(fù)雜,而Facade會減少它們之間的依賴---子系統(tǒng)通過Facade對象向外提供服務(wù)。維護(hù)階段維護(hù)一個遺留的大系統(tǒng)時，F(xiàn)acade可以負(fù)責(zé)與遺留代碼的復(fù)雜的交互工作。13.5外觀模式總結(jié)從客戶程序的角度來看，F(xiàn)acade模式不僅簡化了整個組件系統(tǒng)的接口，同時對于組件內(nèi)部與外部客戶程序來說，從某種程度上也達(dá)到了一種“解耦”的效果——內(nèi)部子系統(tǒng)的任何變化不會影響到Facade接口的變化。Facade設(shè)計模式更注重從架構(gòu)的層次去看整個系統(tǒng)，而不是單個類的層次。Facade很多時候更是一種架構(gòu)設(shè)計模式。注意區(qū)分Facade模式、Adapter模式、Bridge模式與Decorator模式：Facade模式注重簡化接口Ada