C++設計形式之橋接形式。本站提示廣大學習愛好者：（C++設計形式之橋接形式）文章只能為提供參考，不一定能成為您想要的結果。以下是C++設計形式之橋接形式正文
成績描寫
如今要去畫一個圖形，圖形有長方形、圓形和扇形等等；而圖形又可以加上分歧的色彩，然後，我們便可以畫出白色的長方形，綠色的長方形；白色的圓形，綠色的圓形等等。而這類圖形的外形在變更，圖形的色彩也在變更，當應用代碼去完成時，若何面臨這類多方面的變更呢？這就要說到明天的橋接形式了。
甚麼是橋接形式？
關於上述的圖形與色彩的成績時，許多時刻，我們讓各個圖形類繼續色彩類，好比：
class CShape
{
};
class CRectangle : public CShape
{
};
class CCircle : public CShape
{
};
class CColor
{
};
class CRed : public CColor
{
};
class CBlue : public CColor
{
};
class CRedRectangle : public CRed
{
};
class CBlueRectangle : public CBlue
{
};
每當我們增長一個新的圖形，或許增長一種新的色彩時，對應的類就會以相乘的速度停止增長。當體系中的類變的多時，對應的治理也就變的龐雜，這不是我們願望看到的。同時，我們可以看到CRedRectangle類繼續自CRed類，這類繼續關系公道嗎？且不說有的體系是如斯完成的，白色的矩形是白色嗎？很明顯，CRedRectangle和CRed之間不是一種is-a的關系，所以，下面的完成是及其不公道的。那末它們是甚麼關系呢？接著往下看。
在GOF的《設計形式:可復用面向對象軟件的基本》一書中對橋接形式是如許說的：將籠統部門和它的完成部門分別，使它們都可以自力的變更。簡略粗魯的說，就是籠統對外供給挪用的接口；對外隱瞞完成部門，在籠統中援用完成部門，從而完成籠統對完成部門的挪用，而籠統中援用的完成部門可以在往後的開辟進程中，切換成其余完成部門。
為何要應用橋接形式？
當一個籠統能夠有多個完成時，平日用繼續來調和它們。籠統類界說對該籠統的接口，而詳細的子類則用分歧方法加以完成。然則此辦法有時不敷靈巧。繼續機制將籠統部門與它的完成部門固定在一路，使得難以對籠統部門和完成部門自力的停止修正、擴大和重用。橋接形式把依附詳細完成，晉升為依附籠統，來完成對象和變更身分之間的低耦合，進步體系的可保護性和擴大性。橋接形式的重要目標是將一個對象的變更與其它變更隔分開，讓彼此之間的耦合度最低。
甚麼時刻應用橋接形式？
1.假如不願望在籠統和它的完成部門之間有一個固定的綁定關系，也就是繼續關系；假如我們打破了這類固定的綁定關系，今後，便可以便利的在籠統部門切換分歧的完成部門；
2.假如願望類的籠統和它的完成都應當可以經由過程生成子類的辦法加以擴大；假如不應用橋接形式，應用繼續去完成時，在籠統類中添加一個辦法，則在對應的完成類中也須要做對應的修改，這類完成不相符松耦合的請求；
3.假如請求對一個籠統的完成部門的修正對客戶不發生影響，即客戶的代碼不須要從新編譯，在前面的項目經歷會說這方面；
4.假如想對客戶完整隱蔽籠統的完成部門；
5.假如一個對象有多個變更身分的時刻，經由過程籠統這些變更身分，將依附詳細完成，修正為依附籠統；
6.假如某個變更身分在多個對象中同享時，可以籠統出這個變更身分，然後完成這些分歧的變更身分。
下面應用的場景，是一種建議，也是一種參考。在項目中要很好的掌握一個設計形式，是有必定的難度的；當在現實項目中碰到知足下面的一點或許幾點時，可以斟酌應用橋接形式。
UML類圖
Abstraction類界說了籠統類的接口，而且保護一個指向Implementor完成類的指針；
RefineAbstraction類擴大了Abstraction類的接口；
Implementor類界說了完成類的接口，這個接口紛歧定要與Abstraction的接口完整分歧；現實上，這兩個接口可以完整分歧；
ConcreteImplementor類完成了Implementor界說的接口。
代碼完成
/*
** FileName : BridgePatternDemo
** Author : Jelly Young
** Date : 2013/12/4
** Description : More information, please go to http://www.jb51.net
*/
#include <iostream>
using namespace std;
class Implementor
{
public:
virtual void OperationImpl() = 0;
};
class ConcreteImpementor : public Implementor
{
public:
void OperationImpl()
{
cout<<"OperationImpl"<<endl;
}
};
class Abstraction
{
public:
Abstraction(Implementor *pImpl) : m_pImpl(pImpl){}
virtual void Operation() = 0;
protected:
Implementor *m_pImpl;
};
class RedfinedAbstraction : public Abstraction
{
public:
RedfinedAbstraction(Implementor *pImpl) : Abstraction(pImpl){}
void Operation()
{
m_pImpl->OperationImpl();
}
};
int main(int argc, char *argv[])
{
Implementor *pImplObj = new ConcreteImpementor();
Abstraction *pAbsObj = new RedfinedAbstraction(pImplObj);
pAbsObj->Operation();
delete pImplObj;
pImplObj = NULL;
delete pAbsObj;
pAbsObj = NULL;
return 0;
}
依據對代碼的懂得，能想象到CRedRectangle和CRed是甚麼關系嗎？我們可以懂得為白色的矩形包括白色，也就是包括的關系，也就是軟件設計中的組合關系(has-a)。
項目經歷
這是一個我閱歷的項目，也是做起來比擬輕松的一個項目。項目是如許的，須要對一個中央的通訊庫停止改寫，保存之前的通訊方法的同時，須要應用一種新的通訊協定去和底層模塊停止通訊。現有的代碼是一個COM法式，向外供給了可以挪用的接口。依據客戶供給的源碼，我們停止了剖析；在剖析之前，我們有一種擔憂，就是怕用戶的代碼是接口和完成混在一路的；然則，剖析以後，讓我們很受驚，客戶的代碼構造很清楚，條理異常清晰，代碼中應用的就是我們明天這裡說的橋接形式。因為籠統的接口和完成完整停止了分別，我們在停止重寫時，只須要完成我們的一個類，然後在接口中援用我們完成的類，就年夜功樂成了，如許做到了客戶端不須要做任何修正，便可以完善的調換失落本來的通訊層，真的是後人栽樹樹，先人納涼啊。
總結
橋接形式使得籠統和完成停止了分別，籠統不消依附於完成，讓籠統和完成部門各自修正起來都很便利，應用組合（就是Abstraction類中包括了Implementor）的方法，下降了耦合度，同時也有助於分層，從而發生更好的構造化體系。經由過程現實的項目經歷，應用了橋接形式的代碼，對今後的擴大有很年夜的贊助。
