問題描述
現在要去畫乙個圖形，圖形有長方形、圓形和扇形等等；而圖形又可以加上不同的顏色，然後，我們就可以畫出紅色的長方形，綠色的長方形；紅色的圓形，綠色的圓形等等。而這種圖形的形狀在變化，圖形的顏色也在變化，當使用**去實現時，如何面對這種多方面的變化呢？這就要說到今天的橋接模式了。
什麼是橋接模式？
對於上述的圖形與顏色的問題時，很多時候，我們讓各個圖形類繼承顏色類，比如：
複製** **如下:
class cshape
;class crectangle : public cshape
;class ccircle : public cshape
;class ccolor
;clas程式設計客棧s 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
*/#include
using namespace std;
class implementor
;class concreteimpementor : public implementor
};class abstraction
virtual void operation() = 0;
protected:
implementor *m_pimpl;
};class redfinedabstraction : public abstraction
void operation()
};int main(int argc, char *ar**)
根據對**的理解，能想象到credrectangle程式設計客棧和cred是什麼關係嗎？我們可以理解為紅色的矩形包含紅色，也就是包含的關係，也就是軟體設計中的組合關係(has-a)。
專案經驗
這是乙個我經歷的專案，也是做起來比較輕鬆的乙個專案。專案是這樣的，需要對乙個中間的通訊庫進行改寫，保留以前的通訊方式的同時，需要使用一種新的通訊協議去和底層模組進行通訊。現有的**是乙個com程式，向外提供了可以呼叫的介面。根據客戶提供的原始碼，我們進行了分析；在分析之前，我們有一種擔心，就是怕使用者的**是介面和實現混在一起的；但是，分析之後，讓我們很吃驚，客戶的**結構很清晰，層次非常清楚，**中使用的就是我們今天這裡說的橋接模式。由於抽象的介面和實現完全進行了分離，我們在進行重寫時，只需要實現我們的乙個類，然後在介面中引用我們實現的類，就大功告成了，這樣做到了客戶端不需要做任何修改，就可以完美的替換掉原來的通訊層，真的是前人栽樹樹，後人乘涼啊。
總結橋接模式使得抽象和實現進行了分離，抽象不用依賴於實現，讓抽象和實現部分各自修改起來都很方便，使用組合（就是abstraction類中包含了implementor）的方式，降低了耦合度，同時也有助於分層，從而產生更好的結構化系統。通過實際的專案經驗，使用了橋接模式的**，對以後的擴充套件有很大的幫助。
本文標題: c++設計模式之橋接模式
本文位址: /ruanjian/c/114510.html
C 設計模式之橋接模式
橋接模式，合成，聚合復用原則 include using namespace std class soft class notepad public soft class qtcreator public soft class computer virtual void run 0 class le...
C 設計模式之橋接
ironman之橋接 前言 前面的幾個篇幅都是在講 部件 的生產已經簡簡單單的使用，以後可能要對 部件 進行公升級，不是不對它本身公升級，是其它方式的公升級，可以讓它配備 有沒有感覺 部件 是越來越強大了，事物的衍變都是有個過程的嘛，必須要越來越完善，這是 ironman 設計的宗旨。好了,廢話不多...
設計模式之橋接模式
public class test 兩個維度 乙個是具體產品，如狗 豬 乙個是抽象產品，如溫順的動物 冷酷的動物 排列組合 如溫順的狗 冷酷的豬等 abstract class animal 該橋接類的引入是關鍵 abstract class animalbridge extends animal ...