問題描述

現在要去畫一個圖形，圖形有長方形、圓形和扇形等等；而圖形又可以加上不同的顏色，然后，我們就可以畫出紅色的長方形，綠色的長方形；紅色的圓形，綠色的圓形等等。而這種圖形的形狀在變化，圖形的顏色也在變化，當使用代碼去實現時，如何面對這種多方面的變化呢？這就要說到今天的橋接模式了。

什么是橋接模式？

對于上述的圖形與顏色的問題時，很多時候，我們讓各個圖形類繼承顏色類，比如：

每當我們增加一個新的圖形，或者增加一種新的顏色時，對應的類就會以相乘的速度進行增加。當系統中的類變的多時，對應的管理也就變的復雜，這不是我們希望看到的。同時，我們可以看到CRedRectangle類繼承自CRed類，這種繼承關系合理嗎？且不說有的系統是如此實現的，紅色的矩形是紅色嗎？很顯然，CRedRectangle和CRed之間不是一種is-a的關系，所以，上面的實現是及其不合理的。那么它們是什么關系呢？接著往下看。

在GOF的《設計模式:可復用面向對象軟件的基礎》一書中對橋接模式是這樣說的：將抽象部分和它的實現部分分離，使它們都可以獨立的變化。簡單粗暴的說，就是抽象對外提供調用的接口；對外隱瞞實現部分，在抽象中引用實現部分，從而實現抽象對實現部分的調用，而抽象中引用的實現部分可以在今后的開發過程中，切換成別的實現部分。

為什么要使用橋接模式？

當一個抽象可能有多個實現時，通常用繼承來協調它們。抽象類定義對該抽象的接口，而具體的子類則用不同方式加以實現。但是此方法有時不夠靈活。繼承機制將抽象部分與它的實現部分固定在一起，使得難以對抽象部分和實現部分獨立的進行修改、擴充和重用。橋接模式把依賴具體實現，提升為依賴抽象，來完成對象和變化因素之間的低耦合，提高系統的可維護性和擴展性。橋接模式的主要目的是將一個對象的變化與其它變化隔離開，讓彼此之間的耦合度最低。

什么時候使用橋接模式？

1.如果不希望在抽象和它的實現部分之間有一個固定的綁定關系，也就是繼承關系；如果我們打破了這種固定的綁定關系，以后，就可以方便的在抽象部分切換不同的實現部分；

2.如果希望類的抽象以及它的實現都應該可以通過生成子類的方法加以擴充；如果不使用橋接模式，使用繼承去實現時，在抽象類中添加一個方法，則在對應的實現類中也需要做對應的改動，這種實現不符合松耦合的要求；

3.如果要求對一個抽象的實現部分的修改對客戶不產生影響，即客戶的代碼不需要重新編譯，在后面的項目經驗會說這方面；

4.如果想對客戶完全隱藏抽象的實現部分；

5.如果一個對象有多個變化因素的時候，通過抽象這些變化因素，將依賴具體實現，修改為依賴抽象；

6.如果某個變化因素在多個對象中共享時，可以抽象出這個變化因素，然后實現這些不同的變化因素。

上面使用的場景，是一種建議，也是一種參考。在項目中要很好的把握一個設計模式，是有一定的難度的；當在實際項目中遇到滿足上面的一點或者幾點時，可以考慮使用橋接模式。

UML類圖

Abstraction類定義了抽象類的接口，并且維護一個指向Implementor實現類的指針；

RefineAbstraction類擴充了Abstraction類的接口；

Implementor類定義了實現類的接口，這個接口不一定要與Abstraction的接口完全一致；實際上，這兩個接口可以完全不同；

ConcreteImplementor類實現了Implementor定義的接口。

代碼實現

根據對代碼的理解，能想象到CRedRectangle和CRed是什么關系嗎？我們可以理解為紅色的矩形包含紅色，也就是包含的關系，也就是軟件設計中的組合關系(has-a)。

項目經驗

這是一個我經歷的項目，也是做起來比較輕松的一個項目。項目是這樣的，需要對一個中間的通信庫進行改寫，保留以前的通信方式的同時，需要使用一種新的通信協議去和底層模塊進行通信?，F有的代碼是一個COM程序，向外提供了可以調用的接口。根據客戶提供的源碼，我們進行了分析；在分析之前，我們有一種擔心，就是怕用戶的代碼是接口和實現混在一起的；但是，分析之后，讓我們很吃驚，客戶的代碼結構很清晰，層次非常清楚，代碼中使用的就是我們今天這里說的橋接模式。由于抽象的接口和實現完全進行了分離，我們在進行重寫時，只需要實現我們的一個類，然后在接口中引用我們實現的類，就大功告成了，這樣做到了客戶端不需要做任何修改，就可以完美的替換掉原來的通信層，真的是前人栽樹樹，后人乘涼啊。

總結

橋接模式使得抽象和實現進行了分離，抽象不用依賴于實現，讓抽象和實現部分各自修改起來都很方便，使用組合（就是Abstraction類中包含了Implementor）的方式，降低了耦合度，同時也有助于分層，從而產生更好的結構化系統。通過實際的項目經驗，使用了橋接模式的代碼，對以后的擴展有很大的幫助。