系統(tǒng)的復(fù)雜度

　　假設(shè)我們需要開發(fā)一個坦克模擬系統(tǒng)用于模擬坦克車在各種作戰(zhàn)環(huán)境中的行為，其中坦克系統(tǒng)由引擎、控制器、車輪、車身等各子系統(tǒng)構(gòu)成。

　　如何使用這樣的系統(tǒng)

　　動機(jī)（Motivation）

　　上述A方案的問題在于組件的客戶（即外部接口，或客戶程序）和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化，這種過多的耦合面臨很多變化的挑戰(zhàn)。如何簡化外部客戶程序和系統(tǒng)間的交互接口？如何將外部客戶程序的演化和內(nèi)部子系統(tǒng)的變化之間的依賴相互解耦？

　　意圖（Intent）

　　為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設(shè)計模式》GoF

　　例說Facade應(yīng)用

　　以前面的例子為例

　　我們所說的接口其實(shí)并不一定是Interface，只要是Public方法，能被外部調(diào)用的方法都叫接口，這里的定義其實(shí)是更加廣義的接口定義，即露在外面和外界所交互的這一部分。這里主系統(tǒng)和子系統(tǒng)之間的關(guān)系不是繼承關(guān)系，而應(yīng)該是一種包含的關(guān)系。

　　這樣在外部使用的時候只能使用TankFacade類和里面的Start、Stop等方法，其他子系統(tǒng)都被包含在內(nèi)部了。這樣減輕了使用的復(fù)雜度，客戶程序只用關(guān)心TankFacade，而不用關(guān)心里面的子系統(tǒng)情況。更重要的是，這樣的設(shè)計有效地把客戶程序和子系統(tǒng)解耦。

　　結(jié)構(gòu)（Structure）

　　這種結(jié)構(gòu)不僅體現(xiàn)了類的單一職責(zé)原則，而且也體現(xiàn)了開放封閉原則。而且子系統(tǒng)和系統(tǒng)之間是個組合關(guān)系，而不是繼承關(guān)系。高層總是相對穩(wěn)定，低層總是相對易變。所以我們應(yīng)該盡量依賴高層抽象，而不是低層細(xì)節(jié)實(shí)現(xiàn)。

　　Facade模式的幾個要點(diǎn)

　　從客戶程序的角度來看，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模式注重簡化接口

　　Adapter模式注重轉(zhuǎn)換接口

　　Bridge模式注重分離接口（抽象）與其實(shí)現(xiàn)

　　Decorator模式注重穩(wěn)定接口的前提下為對象擴(kuò)展功能

　　.NET架構(gòu)中的Facade應(yīng)用

　　假如我們做一個網(wǎng)上購物系統(tǒng)，考慮它的認(rèn)證系統(tǒng)。用戶權(quán)限不同，能做的事情也不同，它可能會調(diào)用各種各樣的子系統(tǒng)。認(rèn)證系統(tǒng)里面也可能包含很多子系統(tǒng)，比如第三方認(rèn)證等等。這些認(rèn)證子系統(tǒng)合作起來豐富了我們網(wǎng)站的功能，那么這種情況我們就可以考慮把認(rèn)證的各個子系統(tǒng)封裝成一個認(rèn)證系統(tǒng)。

　　如果我們想做跨平臺的及時聊天工具，我們也可以用一個Facade封裝某個平臺系統(tǒng)的API接口。這樣我們在使用API的時候，就不需要去關(guān)心平臺內(nèi)部的變化。

it知識庫：C#面向?qū)ο笤O(shè)計模式縱橫談：Facade 外觀模式，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。