前言

在實(shí)際開發(fā)時(shí)，面對一個(gè)大的系統(tǒng)，總是會將一個(gè)大的系統(tǒng)分成若干個(gè)子系統(tǒng)，等子系統(tǒng)完成之后，再分別調(diào)用對應(yīng)的子系統(tǒng)來完成對應(yīng)的整體功能，這樣有利于降低系統(tǒng)的復(fù)雜性；最終進(jìn)行實(shí)現(xiàn)某個(gè)具體的功能時(shí)，我們將對應(yīng)的子系統(tǒng)進(jìn)行組合就好了；但是，子系統(tǒng)那么多，關(guān)系那么復(fù)雜，組合形成一個(gè)完整的系統(tǒng)，是存在難度的。

我們在使用visual studio進(jìn)行編譯C++代碼時(shí)，你只是在菜單中選擇了Build，然后visual studio就開始了一堆的編譯工作；你應(yīng)該知道，因?yàn)槟愕囊粋€(gè)簡單的Build動作，編譯器在后臺會進(jìn)行語法分析，生成中間代碼，生成匯編代碼，鏈接成可執(zhí)行程序或庫等等動作；而這一切，作為只是開發(fā)程序的我們，而不用去理解編譯器在做什么的，編譯器向我們隱藏了背后的一系列復(fù)雜操作，而只提供一個(gè)Build按鈕，這個(gè)Build按鈕，就可以執(zhí)行一切的操作；當(dāng)單擊這個(gè)Build按鈕時(shí)，Build在幕后，將任務(wù)分發(fā)給不同的子系統(tǒng)去完成，最終子系統(tǒng)進(jìn)行協(xié)作完成了整個(gè)的編譯任務(wù)。而這樣隱藏一些復(fù)雜操作，只提供一個(gè)更高層的統(tǒng)一接口，就是我今天總結(jié)的外觀模式。

什么是外觀模式？

外觀模式，很多人也把它叫做門面模式。在GOF的《設(shè)計(jì)模式:可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中對外觀模式是這樣說的：將子系統(tǒng)中的一組接口提供一個(gè)一致的界面，外觀模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。細(xì)細(xì)的理解這句話；子系統(tǒng)中的一組接口，就好比上面舉得例子中的語法分析，生成中間代碼，生成匯編代碼，鏈接成可執(zhí)行程序或庫；外觀模式定義的一個(gè)高層接口，就好比上面說的Build按鈕，通過這樣的一個(gè)Build按鈕，讓編譯器更加容易使用，對于這一點(diǎn)，從Linux C++/C轉(zhuǎn)Windows C++/C的程序員是最有體會的。visual studio提供的強(qiáng)大功能，只需要一個(gè)Build按鈕，就可以進(jìn)行Build動作，而不需要去寫makefile文件，然后再去執(zhí)行一些命令進(jìn)行編譯。

UML類圖

Facade:知道哪些子系統(tǒng)類負(fù)責(zé)處理請求，并且將客戶的請求代理給適當(dāng)?shù)淖酉到y(tǒng)對象；

SubSystem:實(shí)現(xiàn)子系統(tǒng)具體的功能；處理由Facade對象指派的任務(wù)；但是，SubSystem沒有Facade的任何相關(guān)信息，也就是說，沒有指向Facade的指針。

Client通過發(fā)送請求給Facade的方式與子系統(tǒng)進(jìn)行通信，而不直接與子系統(tǒng)打交道，F(xiàn)acade將這些消息轉(zhuǎn)發(fā)給適當(dāng)?shù)淖酉到y(tǒng)對象。盡管是子系統(tǒng)中的有關(guān)對象在做實(shí)際工作，但Facade模式本身也必須將它的接口轉(zhuǎn)換成子系統(tǒng)的接口，這里是不是有點(diǎn)適配器模式的感覺呢？這就是學(xué)習(xí)結(jié)構(gòu)型設(shè)計(jì)模式的感覺，感覺都很相似，但是仔細(xì)的去研究時(shí)，就會發(fā)現(xiàn)各自的用處。

代碼實(shí)現(xiàn)

這里實(shí)現(xiàn)的代碼就是參照我上面舉的編譯器的例子。

上面的代碼很簡單。我們可以想象，如果沒有使用外觀模式，在客戶端如果要進(jìn)行Compile同樣的動作時(shí)，就需要寫一堆和Compile中一樣的代碼；是的，你會說，寫就寫吧。但是，有的時(shí)候，客戶端并不會非常熟悉子系統(tǒng)之間的關(guān)系，就好比，先要進(jìn)行語法分析，再生成中間代碼，然后生成匯編語言，最后進(jìn)行鏈接一樣。如果客戶端不知道這個(gè)時(shí)序，那怎么辦？所以，外觀模式讓一切復(fù)雜的東西，使用起來都變的簡單了。

優(yōu)點(diǎn)

1.它對客戶屏蔽了子系統(tǒng)組件，因而減少了客戶處理的對象的數(shù)目，并使得子系統(tǒng)使用起來更加方便；

2.它實(shí)現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系，而子系統(tǒng)內(nèi)部的功能組件往往是緊耦合的；松耦合系統(tǒng)使得子系統(tǒng)的組件變化不會影響到它的客戶。外觀模式有助于建立層次結(jié)構(gòu)系統(tǒng)，也有助于對對象之間的依賴關(guān)系分層。外觀模式可以消除復(fù)雜的循環(huán)依賴關(guān)系。這一點(diǎn)在客戶程序與子系統(tǒng)是分別實(shí)現(xiàn)的時(shí)候尤為重要。

使用場合

1.當(dāng)你要為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡單接口時(shí)。子系統(tǒng)往往因?yàn)椴粩嘌莼兊脑絹碓綇?fù)雜。大多數(shù)模式使用時(shí)都會產(chǎn)生更多更小的類。這使得子系統(tǒng)更具有可重用性，也更容易對子系統(tǒng)進(jìn)行定制，但這也給那些不需要定制子系統(tǒng)的用戶帶來一些使用上的困難。外觀模式可以提供一個(gè)簡單的缺省視圖，這一視圖對大多數(shù)用戶來說已經(jīng)足夠，而那些需要更多的可定制性的用戶可以越過Facade層；

2.當(dāng)客戶程序與抽象類的實(shí)現(xiàn)部分之間存在很大的依賴性。引入Facade將這個(gè)子系統(tǒng)與客戶以及其他的子系統(tǒng)分離，可以提高子系統(tǒng)的獨(dú)立性和可移植性；

3.當(dāng)需要構(gòu)建一個(gè)層次結(jié)構(gòu)的子系統(tǒng)時(shí)，使用外觀模式定義子系統(tǒng)中每層的入口點(diǎn)。如果子系統(tǒng)之間是相互依賴的，我們就可以讓它們僅通過Facade進(jìn)行通訊，從而簡化了它們之間的依賴關(guān)系。

總結(jié)

外觀模式簡單易用，讓客戶能更簡單的去使用子系統(tǒng)；在拜讀別人的文章時(shí)，有以下總結(jié)非常好，我也借鑒一下：

1.在設(shè)計(jì)初期，應(yīng)該有意識的將不同層分離，比如常用的三層架構(gòu)，就是考慮在數(shù)據(jù)訪問層，與業(yè)務(wù)邏輯層表示層之間，建立Facade，使復(fù)雜的子系統(tǒng)提供一個(gè)簡單的接口，降低耦合性；

2.在開發(fā)階段，子系統(tǒng)往往因?yàn)椴粩嗟闹貥?gòu)而變的越來越復(fù)雜，增加外觀Facade可以提供一個(gè)簡單的接口，減少它們之間的依賴；

3.在維護(hù)階段，可能這個(gè)系統(tǒng)已經(jīng)非常難以維護(hù)和擴(kuò)展了，此時(shí)你可以為新系統(tǒng)開發(fā)一個(gè)外觀類，來提供設(shè)計(jì)粗糙或高度復(fù)雜的遺留代碼的比較清晰簡單的接口，讓新系統(tǒng)與Facade對象交互，F(xiàn)acade與遺留代碼交互所有復(fù)雜的工作。

通常來講，對于子系統(tǒng)的訪問，我們提供一個(gè)Facade層，而這個(gè)Facade入口，只需要一個(gè)；也就是說在使用Facade時(shí)，我們可以使用單例模式來實(shí)現(xiàn)Facade模式。對于外觀模式到此就總結(jié)完成了，肯定有一些地方遺漏了，請大家指正。我堅(jiān)信，分享使我們更加進(jìn)步。

最新評論