系統(tǒng)的復(fù)雜度
假設(shè)我們需要開發(fā)一個(gè)坦克模擬系統(tǒng)用于模擬坦克車在各種作戰(zhàn)環(huán)境中的行為,其中坦克系統(tǒng)由引擎、控制器、車輪、車身等各子系統(tǒng)構(gòu)成。
如何使用這樣的系統(tǒng)
動(dòng)機(jī)(Motivation)
上述A方案的問(wèn)題在于組件的客戶(即外部接口,或客戶程序)和組件中各種復(fù)雜的子系統(tǒng)有了過(guò)多的耦合,隨著外部客戶程序和各子系統(tǒng)的演化,這種過(guò)多的耦合面臨很多變化的挑戰(zhàn)。如何簡(jiǎn)化外部客戶程序和系統(tǒng)間的交互接口?如何將外部客戶程序的演化和內(nèi)部子系統(tǒng)的變化之間的依賴相互解耦?
意圖(Intent)
為子系統(tǒng)中的一組接口提供一個(gè)一致的界面,F(xiàn)acade模式定義了一個(gè)高層接口,這個(gè)接口使得這一子系統(tǒng)更加容易使用。
——《設(shè)計(jì)模式》GoF
例說(shuō)Facade應(yīng)用
以前面的例子為例
我們所說(shuō)的接口其實(shí)并不一定是Interface,只要是Public方法,能被外部調(diào)用的方法都叫接口,這里的定義其實(shí)是更加廣義的接口定義,即露在外面和外界所交互的這一部分。這里主系統(tǒng)和子系統(tǒng)之間的關(guān)系不是繼承關(guān)系,而應(yīng)該是一種包含的關(guān)系。
這樣在外部使用的時(shí)候只能使用TankFacade類和里面的Start、Stop等方法,其他子系統(tǒng)都被包含在內(nèi)部了。這樣減輕了使用的復(fù)雜度,客戶程序只用關(guān)心TankFacade,而不用關(guān)心里面的子系統(tǒng)情況。更重要的是,這樣的設(shè)計(jì)有效地把客戶程序和子系統(tǒng)解耦。
結(jié)構(gòu)(Structure)
這種結(jié)構(gòu)不僅體現(xiàn)了類的單一職責(zé)原則,而且也體現(xiàn)了開放封閉原則。而且子系統(tǒng)和系統(tǒng)之間是個(gè)組合關(guān)系,而不是繼承關(guān)系。高層總是相對(duì)穩(wěn)定,低層總是相對(duì)易變。所以我們應(yīng)該盡量依賴高層抽象,而不是低層細(xì)節(jié)實(shí)現(xiàn)。
Facade模式的幾個(gè)要點(diǎn)
從客戶程序的角度來(lái)看,F(xiàn)acade模式不僅簡(jiǎn)化了整個(gè)組件系統(tǒng)的接口,同時(shí)對(duì)于組件內(nèi)部與外部客戶程序來(lái)說(shuō),從某種程度上也達(dá)到了一種“解耦”的效果——內(nèi)部子系統(tǒng)的任何變化不會(huì)影響到Facade接口的變化。
Facade設(shè)計(jì)模式更注重從架構(gòu)的層次去看整個(gè)系統(tǒng),而不是單個(gè)類的層次。Facade很多時(shí)候更是一種架構(gòu)設(shè)計(jì)模式。
注意區(qū)分Facade模式、Adapter模式、Bridge模式與Decorator模式:
Facade模式注重簡(jiǎn)化接口
Adapter模式注重轉(zhuǎn)換接口
Bridge模式注重分離接口(抽象)與其實(shí)現(xiàn)
Decorator模式注重穩(wěn)定接口的前提下為對(duì)象擴(kuò)展功能
.NET架構(gòu)中的Facade應(yīng)用
假如我們做一個(gè)網(wǎng)上購(gòu)物系統(tǒng),考慮它的認(rèn)證系統(tǒng)。用戶權(quán)限不同,能做的事情也不同,它可能會(huì)調(diào)用各種各樣的子系統(tǒng)。認(rèn)證系統(tǒng)里面也可能包含很多子系統(tǒng),比如第三方認(rèn)證等等。這些認(rèn)證子系統(tǒng)合作起來(lái)豐富了我們網(wǎng)站的功能,那么這種情況我們就可以考慮把認(rèn)證的各個(gè)子系統(tǒng)封裝成一個(gè)認(rèn)證系統(tǒng)。
如果我們想做跨平臺(tái)的及時(shí)聊天工具,我們也可以用一個(gè)Facade封裝某個(gè)平臺(tái)系統(tǒng)的API接口。這樣我們?cè)谑褂肁PI的時(shí)候,就不需要去關(guān)心平臺(tái)內(nèi)部的變化。
聯(lián)系客服