前言
在實(shí)際開(kāi)發(fā)時(shí),面對(duì)一個(gè)大的系統(tǒng),總是會(huì)將一個(gè)大的系統(tǒng)分成若干個(gè)子系統(tǒng),等子系統(tǒng)完成之后,再分別調(diào)用對(duì)應(yīng)的子系統(tǒng)來(lái)完成對(duì)應(yīng)的整體功能,這樣有利于降低系統(tǒng)的復(fù)雜性;最終進(jìn)行實(shí)現(xiàn)某個(gè)具體的功能時(shí),我們將對(duì)應(yīng)的子系統(tǒng)進(jìn)行組合就好了;但是,子系統(tǒng)那么多,關(guān)系那么復(fù)雜,組合形成一個(gè)完整的系統(tǒng),是存在難度的。
我們?cè)谑褂胿isual studio進(jìn)行編譯C++代碼時(shí),你只是在菜單中選擇了Build,然后visual studio就開(kāi)始了一堆的編譯工作;你應(yīng)該知道,因?yàn)槟愕囊粋€(gè)簡(jiǎn)單的Build動(dòng)作,編譯器在后臺(tái)會(huì)進(jìn)行語(yǔ)法分析,生成中間代碼,生成匯編代碼,鏈接成可執(zhí)行程序或庫(kù)等等動(dòng)作;而這一切,作為只是開(kāi)發(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é)的外觀(guān)模式。
什么是外觀(guān)模式?
外觀(guān)模式,很多人也把它叫做門(mén)面模式。在GOF的《設(shè)計(jì)模式:可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書(shū)中對(duì)外觀(guān)模式是這樣說(shuō)的:將子系統(tǒng)中的一組接口提供一個(gè)一致的界面,外觀(guān)模式定義了一個(gè)高層接口,這個(gè)接口使得這一子系統(tǒng)更加容易使用。細(xì)細(xì)的理解這句話(huà);子系統(tǒng)中的一組接口,就好比上面舉得例子中的語(yǔ)法分析,生成中間代碼,生成匯編代碼,鏈接成可執(zhí)行程序或庫(kù);外觀(guān)模式定義的一個(gè)高層接口,就好比上面說(shuō)的Build按鈕,通過(guò)這樣的一個(gè)Build按鈕,讓編譯器更加容易使用,對(duì)于這一點(diǎn),從Linux C++/C轉(zhuǎn)Windows C++/C的程序員是最有體會(huì)的。visual studio提供的強(qiáng)大功能,只需要一個(gè)Build按鈕,就可以進(jìn)行Build動(dòng)作,而不需要去寫(xiě)makefile文件,然后再去執(zhí)行一些命令進(jìn)行編譯。
UML類(lèi)圖
Facade:知道哪些子系統(tǒng)類(lèi)負(fù)責(zé)處理請(qǐng)求,并且將客戶(hù)的請(qǐng)求代理給適當(dāng)?shù)淖酉到y(tǒng)對(duì)象;
SubSystem:實(shí)現(xiàn)子系統(tǒng)具體的功能;處理由Facade對(duì)象指派的任務(wù);但是,SubSystem沒(méi)有Facade的任何相關(guān)信息,也就是說(shuō),沒(méi)有指向Facade的指針。
Client通過(guò)發(fā)送請(qǐng)求給Facade的方式與子系統(tǒng)進(jìn)行通信,而不直接與子系統(tǒng)打交道,F(xiàn)acade將這些消息轉(zhuǎn)發(fā)給適當(dāng)?shù)淖酉到y(tǒng)對(duì)象。盡管是子系統(tǒng)中的有關(guān)對(duì)象在做實(shí)際工作,但Facade模式本身也必須將它的接口轉(zhuǎn)換成子系統(tǒng)的接口,這里是不是有點(diǎn)適配器模式的感覺(jué)呢?這就是學(xué)習(xí)結(jié)構(gòu)型設(shè)計(jì)模式的感覺(jué),感覺(jué)都很相似,但是仔細(xì)的去研究時(shí),就會(huì)發(fā)現(xiàn)各自的用處。
代碼實(shí)現(xiàn)
這里實(shí)現(xiàn)的代碼就是參照我上面舉的編譯器的例子。
/*
** FileName : FacadePatternDemo
** Author : Jelly Young
** Date : 2014/1/2
** Description : More information, please go to http://www.ythuaji.com.cn
*/
#include <iostream>
using namespace std;
// 語(yǔ)法分析子系統(tǒng)
class CSyntaxParser
{
public:
void SyntaxParser()
{
cout<<"Syntax Parser"<<endl;
}
};
// 生成中間代碼子系統(tǒng)
class CGenMidCode
{
public:
void GenMidCode()
{
cout<<"Generate middle code"<<endl;
}
};
// 生成匯編代碼子系統(tǒng)
class CGenAssemblyCode
{
public:
void GenAssemblyCode()
{
cout<<"Generate assembly code"<<endl;
}
};
// 鏈接生成可執(zhí)行應(yīng)用程序或庫(kù)子系統(tǒng)
class CLinkSystem
{
public:
void LinkSystem()
{
cout<<"Link System"<<endl;
}
};
class Facade
{
public:
void Compile()
{
CSyntaxParser syntaxParser;
CGenMidCode genMidCode;
CGenAssemblyCode genAssemblyCode;
CLinkSystem linkSystem;
syntaxParser.SyntaxParser();
genMidCode.GenMidCode();
genAssemblyCode.GenAssemblyCode();
linkSystem.LinkSystem();
}
};
// 客戶(hù)端
int main()
{
Facade facade;
facade.Compile();
}
上面的代碼很簡(jiǎn)單。我們可以想象,如果沒(méi)有使用外觀(guān)模式,在客戶(hù)端如果要進(jìn)行Compile同樣的動(dòng)作時(shí),就需要寫(xiě)一堆和Compile中一樣的代碼;是的,你會(huì)說(shuō),寫(xiě)就寫(xiě)吧。但是,有的時(shí)候,客戶(hù)端并不會(huì)非常熟悉子系統(tǒng)之間的關(guān)系,就好比,先要進(jìn)行語(yǔ)法分析,再生成中間代碼,然后生成匯編語(yǔ)言,最后進(jìn)行鏈接一樣。如果客戶(hù)端不知道這個(gè)時(shí)序,那怎么辦?所以,外觀(guān)模式讓一切復(fù)雜的東西,使用起來(lái)都變的簡(jiǎn)單了。
優(yōu)點(diǎn)
1.它對(duì)客戶(hù)屏蔽了子系統(tǒng)組件,因而減少了客戶(hù)處理的對(duì)象的數(shù)目,并使得子系統(tǒng)使用起來(lái)更加方便;
2.它實(shí)現(xiàn)了子系統(tǒng)與客戶(hù)之間的松耦合關(guān)系,而子系統(tǒng)內(nèi)部的功能組件往往是緊耦合的;松耦合系統(tǒng)使得子系統(tǒng)的組件變化不會(huì)影響到它的客戶(hù)。外觀(guān)模式有助于建立層次結(jié)構(gòu)系統(tǒng),也有助于對(duì)對(duì)象之間的依賴(lài)關(guān)系分層。外觀(guān)模式可以消除復(fù)雜的循環(huán)依賴(lài)關(guān)系。這一點(diǎn)在客戶(hù)程序與子系統(tǒng)是分別實(shí)現(xiàn)的時(shí)候尤為重要。
使用場(chǎng)合
1.當(dāng)你要為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡(jiǎn)單接口時(shí)。子系統(tǒng)往往因?yàn)椴粩嘌莼兊脑絹?lái)越復(fù)雜。大多數(shù)模式使用時(shí)都會(huì)產(chǎn)生更多更小的類(lèi)。這使得子系統(tǒng)更具有可重用性,也更容易對(duì)子系統(tǒng)進(jìn)行定制,但這也給那些不需要定制子系統(tǒng)的用戶(hù)帶來(lái)一些使用上的困難。外觀(guān)模式可以提供一個(gè)簡(jiǎn)單的缺省視圖,這一視圖對(duì)大多數(shù)用戶(hù)來(lái)說(shuō)已經(jīng)足夠,而那些需要更多的可定制性的用戶(hù)可以越過(guò)Facade層;
2.當(dāng)客戶(hù)程序與抽象類(lèi)的實(shí)現(xiàn)部分之間存在很大的依賴(lài)性。引入Facade將這個(gè)子系統(tǒng)與客戶(hù)以及其他的子系統(tǒng)分離,可以提高子系統(tǒng)的獨(dú)立性和可移植性;
3.當(dāng)需要構(gòu)建一個(gè)層次結(jié)構(gòu)的子系統(tǒng)時(shí),使用外觀(guān)模式定義子系統(tǒng)中每層的入口點(diǎn)。如果子系統(tǒng)之間是相互依賴(lài)的,我們就可以讓它們僅通過(guò)Facade進(jìn)行通訊,從而簡(jiǎn)化了它們之間的依賴(lài)關(guān)系。
總結(jié)
外觀(guān)模式簡(jiǎn)單易用,讓客戶(hù)能更簡(jiǎn)單的去使用子系統(tǒng);在拜讀別人的文章時(shí),有以下總結(jié)非常好,我也借鑒一下:
1.在設(shè)計(jì)初期,應(yīng)該有意識(shí)的將不同層分離,比如常用的三層架構(gòu),就是考慮在數(shù)據(jù)訪(fǎng)問(wèn)層,與業(yè)務(wù)邏輯層表示層之間,建立Facade,使復(fù)雜的子系統(tǒng)提供一個(gè)簡(jiǎn)單的接口,降低耦合性;
2.在開(kāi)發(fā)階段,子系統(tǒng)往往因?yàn)椴粩嗟闹貥?gòu)而變的越來(lái)越復(fù)雜,增加外觀(guān)Facade可以提供一個(gè)簡(jiǎn)單的接口,減少它們之間的依賴(lài);
3.在維護(hù)階段,可能這個(gè)系統(tǒng)已經(jīng)非常難以維護(hù)和擴(kuò)展了,此時(shí)你可以為新系統(tǒng)開(kāi)發(fā)一個(gè)外觀(guān)類(lèi),來(lái)提供設(shè)計(jì)粗糙或高度復(fù)雜的遺留代碼的比較清晰簡(jiǎn)單的接口,讓新系統(tǒng)與Facade對(duì)象交互,F(xiàn)acade與遺留代碼交互所有復(fù)雜的工作。
通常來(lái)講,對(duì)于子系統(tǒng)的訪(fǎng)問(wèn),我們提供一個(gè)Facade層,而這個(gè)Facade入口,只需要一個(gè);也就是說(shuō)在使用Facade時(shí),我們可以使用單例模式來(lái)實(shí)現(xiàn)Facade模式。對(duì)于外觀(guān)模式到此就總結(jié)完成了,肯定有一些地方遺漏了,請(qǐng)大家指正。我堅(jiān)信,分享使我們更加進(jìn)步。