前言
在實際開發時,面對一個大的系統,總是會將一個大的系統分成若干個子系統,等子系統完成之後,再分別調用對應的子系統來完成對應的整體功能,這樣有利於降低系統的複雜性;最終進行實現某個具體的功能時,我們將對應的子系統進行組合就好了;但是,子系統那麼多,關係那麼複雜,組合形成一個完整的系統,是存在難度的。
我們在使用visual studio進行編譯C++代碼時,你只是在菜單中選擇了Build,然後visual studio就開始了一堆的編譯工作;你應該知道,因爲你的一個簡單的Build動作,編譯器在後臺會進行語法分析,生成中間代碼,生成彙編代碼,鏈接成可執行程序或庫等等動作;而這一切,作爲只是開發程序的我們,而不用去理解編譯器在做什麼的,編譯器向我們隱藏了背後的一系列複雜操作,而只提供一個Build按鈕,這個Build按鈕,就可以執行一切的操作;當單擊這個Build按鈕時,Build在幕後,將任務分發給不同的子系統去完成,最終子系統進行協作完成了整個的編譯任務。而這樣隱藏一些複雜操作,只提供一個更高層的統一接口,就是我今天總結的外觀模式。
什麼是外觀模式?
外觀模式,很多人也把它叫做門面模式。在GOF的《設計模式:可複用面向對象軟件的基礎》一書中對外觀模式是這樣說的:將子系統中的一組接口提供一個一致的界面,外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。細細的理解這句話;子系統中的一組接口,就好比上面舉得例子中的語法分析,生成中間代碼,生成彙編代碼,鏈接成可執行程序或庫;外觀模式定義的一個高層接口,就好比上面說的Build按鈕,通過這樣的一個Build按鈕,讓編譯器更加容易使用,對於這一點,從Linux C++/C轉Windows C++/C的程序員是最有體會的。visual studio提供的強大功能,只需要一個Build按鈕,就可以進行Build動作,而不需要去寫makefile文件,然後再去執行一些命令進行編譯。
UML類圖
Facade:知道哪些子系統類負責處理請求,並且將客戶的請求代理給適當的子系統對象;
SubSystem:實現子系統具體的功能;處理由Facade對象指派的任務;但是,SubSystem沒有Facade的任何相關信息,也就是說,沒有指向Facade的指針。
Client通過發送請求給Facade的方式與子系統進行通信,而不直接與子系統打交道,Facade將這些消息轉發給適當的子系統對象。儘管是子系統中的有關對象在做實際工作,但Facade模式本身也必須將它的接口轉換成子系統的接口,這裏是不是有點適配器模式的感覺呢?這就是學習結構型設計模式的感覺,感覺都很相似,但是仔細的去研究時,就會發現各自的用處。
代碼實現
這裏實現的代碼就是參照我上面舉的編譯器的例子。
1 #include <iostream> 2 using namespace std; 3 4 // 語法分析子系統 5 class CSyntaxParser 6 { 7 public: 8 void SyntaxParser() 9 { 10 cout<<"Syntax Parser"<<endl; 11 } 12 }; 13 14 // 生成中間代碼子系統 15 class CGenMidCode 16 { 17 public: 18 void GenMidCode() 19 { 20 cout<<"Generate middle code"<<endl; 21 } 22 }; 23 24 // 生成彙編代碼子系統 25 class CGenAssemblyCode 26 { 27 public: 28 void GenAssemblyCode() 29 { 30 cout<<"Generate assembly code"<<endl; 31 } 32 }; 33 34 // 鏈接生成可執行應用程序或庫子系統 35 class CLinkSystem 36 { 37 public: 38 void LinkSystem() 39 { 40 cout<<"Link System"<<endl; 41 } 42 }; 43 44 class Facade 45 { 46 public: 47 void Compile() 48 { 49 CSyntaxParser syntaxParser; 50 CGenMidCode genMidCode; 51 CGenAssemblyCode genAssemblyCode; 52 CLinkSystem linkSystem; 53 syntaxParser.SyntaxParser(); 54 genMidCode.GenMidCode(); 55 genAssemblyCode.GenAssemblyCode(); 56 linkSystem.LinkSystem(); 57 } 58 }; 59 60 // 客戶端 61 int main() 62 { 63 Facade facade; 64 facade.Compile(); 65 }
上面的代碼很簡單。我們可以想象,如果沒有使用外觀模式,在客戶端如果要進行Compile同樣的動作時,就需要寫一堆和Compile中一樣的代碼;是的,你會說,寫就寫吧。但是,有的時候,客戶端並不會非常熟悉子系統之間的關係,就好比,先要進行語法分析,再生成中間代碼,然後生成彙編語言,最後進行鏈接一樣。如果客戶端不知道這個時序,那怎麼辦?所以,外觀模式讓一切複雜的東西,使用起來都變的簡單了。
優點
- 它對客戶屏蔽了子系統組件,因而減少了客戶處理的對象的數目,並使得子系統使用起來更加方便;
- 它實現了子系統與客戶之間的鬆耦合關係,而子系統內部的功能組件往往是緊耦合的;鬆耦合系統使得子系統的組件變化不會影響到它的客戶。外觀模式有助於建立層次結構系統,也有助於對對象之間的依賴關係分層。外觀模式可以消除複雜的循環依賴關係。這一點在客戶程序與子系統是分別實現的時候尤爲重要。
使用場合
- 當你要爲一個複雜子系統提供一個簡單接口時。子系統往往因爲不斷演化而變的越來越複雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具有可重用性,也更容易對子系統進行定製,但這也給那些不需要定製子系統的用戶帶來一些使用上的困難。外觀模式可以提供一個簡單的缺省視圖,這一視圖對大多數用戶來說已經足夠,而那些需要更多的可定製性的用戶可以越過Facade層;
- 當客戶程序與抽象類的實現部分之間存在很大的依賴性。引入Facade將這個子系統與客戶以及其他的子系統分離,可以提高子系統的獨立性和可移植性;
- 當需要構建一個層次結構的子系統時,使用外觀模式定義子系統中每層的入口點。如果子系統之間是相互依賴的,我們就可以讓它們僅通過Facade進行通訊,從而簡化了它們之間的依賴關係。
總結
外觀模式簡單易用,讓客戶能更簡單的去使用子系統;在拜讀別人的文章時,有以下總結非常好,我也借鑑一下:
- 在設計初期,應該有意識的將不同層分離,比如常用的三層架構,就是考慮在數據訪問層,與業務邏輯層表示層之間,建立Facade,使複雜的子系統提供一個簡單的接口,降低耦合性;
- 在開發階段,子系統往往因爲不斷的重構而變的越來越複雜,增加外觀Facade可以提供一個簡單的接口,減少它們之間的依賴;
- 在維護階段,可能這個系統已經非常難以維護和擴展了,此時你可以爲新系統開發一個外觀類,來提供設計粗糙或高度複雜的遺留代碼的比較清晰簡單的接口,讓新系統與Facade對象交互,Facade與遺留代碼交互所有複雜的工作。
通常來講,對於子系統的訪問,我們提供一個Facade層,而這個Facade入口,只需要一個;也就是說在使用Facade時,我們可以使用單例模式來實現Facade模式。對於外觀模式到此就總結完成了,肯定有一些地方遺漏了,請大家指正。我堅信,分享使我們更加進步。