設(shè)計模式學(xué)習(xí)總結(jié)之四
六：Bridge模式（即：橋接模式）
講之前，先聲明：由于本人電腦不是很好，沒法裝上vc環(huán)境運行。因此以下代碼，僅是手工輸入，在環(huán)境中未必能編譯通過。
但以下，僅僅只是介紹一種思想。僅供參考。同時，如果說明有誤之處，歡迎指正。另外，則于一次性手工輸入下面那么多東東，確實
不容易，所以Delphi的具體實現(xiàn)。就不在此列出。如有興趣用Delphi實現(xiàn)的朋友，也可以找本人交流，本人盛感榮幸。
（當然如果是C++的朋友也同樣、甚至更加歡迎）
看了這么多次的橋接模式，這次總算明白了。要想理解橋接模式，個人認為，還是有必要同抽象及其實現(xiàn)進行一下比較。
1) 抽象及實現(xiàn)。我相信，跟不同的人說話，都會有訣竅在里頭。同是coder，相信，最默契的溝通，還是code吧。我們來看下抽象及其實現(xiàn)的代碼。
//抽象基類聲明
class AbstractClassX
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//AbstractClassX的具體實現(xiàn) ClassXImplX1
class ClassXImplX1 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 1... }
}
//AbstractClassX的具體實現(xiàn) ClassXImplX2
class ClassXImplX2 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 2... }
}
在實際應(yīng)用中，我們用的是抽象類。而實際上實例化的，卻是某具體子類。這種實現(xiàn)被我們多數(shù)人所使用。而它實際上解決的只是這么一類問題，即：同一行為的不同表現(xiàn)。當
然大多數(shù)需求，用此就可以了。
但現(xiàn)在假如說有這么一種情況：假如說，上面的處理僅僅只適用于平臺A，而用戶卻希望同時，它也要能夠在平臺B上也能夠一樣的操作。那當如何？
很明顯的，此種需要，并不是行為上的需求，因為不論是在平臺A上還是平臺B上，都要執(zhí)行相同的操作。而且表示也是一樣的。該需要的實現(xiàn)。實際上是需要我們重新封裝個抽象層，
來專門處理平臺B上的該行為。而實際的實現(xiàn)，卻還是跟平臺A上的一樣。其實我們仔細一想。其實平臺A了的抽象（即：AbstractClassX）與平臺B上的抽象（假如為：AbstractClassY），
其實它們是類似的。因為需要處理的功能一樣。因此，我們就想，如果將這種抽象與實現(xiàn)具體分離開來。在抽象中，留個具體實現(xiàn)的抽象引用（此其實就是該模式所指的Bridge----即：橋
通過該橋，將抽象與具體的實現(xiàn)連接起來。因此，我想該模式的名稱就是因此得來的吧）。那樣。抽象可以不受限制的擴展，實現(xiàn)也同樣可以不受限制的擴展。這樣，系統(tǒng)的框架就不需要
更改，其不妙哉？！因此就有了如下的code
//******************************************************************
//* 抽象聲明及抽象部分的實現(xiàn)
//******************************************************************
//抽象的抽象基類聲明
class AbstractClass
{
private:
//xxx
protected:
AbstractImpl* m_pAIObj; //具體的抽象實現(xiàn)的抽象對象（這話很ao口，但理解了這話，也就理解了該模式。可以大言不慚地說，該模式的秘密就在這句話上）
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//平臺A上的抽象的具體實現(xiàn)(注意：此實現(xiàn)子類，是針對抽象的)
class AbstractClassA : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}
//平臺B上的抽象的具體實現(xiàn)(注意：此實現(xiàn)子類，是針對抽象的)
class AbstractClassB : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}
//******************************************************************
//* 實現(xiàn)的抽象聲明及其實現(xiàn)
//******************************************************************
//實現(xiàn)部分的抽象基類聲明
class AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//具體算法1的具體實現(xiàn)
class ImplX : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}
//具體算法1的具體實現(xiàn)
class ImplY : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}
//******************************************************************
//* 實際應(yīng)用方面
//******************************************************************
int main(int argc, char* argv[])
{
AbstractImplClass* pImplObj = new ImplX();//或new ImplY();等等。
//下面注意下：因為上面的代碼中，本人為了簡寫，并沒有明確寫出抽象部分的具體構(gòu)造函數(shù)。
//相信，是程序員，看完下面這行都懂得，上面的抽象部分的聲明，應(yīng)該聲明一個什么樣的
//構(gòu)造函數(shù)吧。
AbstractClass* pAbstractObj = new AbstractClassA(pImplObj);//或new AbstractClassB(pImplObj);等等。
//do other something...
//在此補充一點：有上面的設(shè)計，系統(tǒng)的框架將都無需修改。不論是實現(xiàn)的具體算法改變了，還是
//抽象的需求變動。程序都無需要修改框架代碼，，僅僅只需要寫個具體的實現(xiàn)類（不管是實現(xiàn)的實現(xiàn)類，還是
//抽象的實現(xiàn)類）即可。這就是橋接模式。
}