Bridge是設計模式中比較複雜和難以理解的模式之一，即使用組合的方式將抽象和實現徹底地解耦，這樣的好處是抽象和實現可以分別獨立地變化，系統的耦合性也得到了很好的降低。
這句話太精簡，以至於我很難知道它在說什麼……
我覺得這麼說更恰當，bridge使用組合的方式，使（抽象A類）和（A類的組成部分抽象B類）的實例化徹底地解耦。這樣說我覺得是最貼切的。
舉個栗子。
我想要創作一個筆類，那麼做爲筆它要可以畫出顏色，不同的筆可以有不同的顏色，所以我將筆作爲基類，畫顏色作爲它的一個虛函數（可被繼承）。結構如下圖。
之後我們可以創建出紅筆、藍筆、黑筆，都繼承自Pen類，如下圖。
這樣一看好似沒什麼問題，很多人都會這麼去創作這麼個Pen繼承體系。我們接着往下走。
有人要買我的Pen體系了，但他要求Pen類要細分爲大、中、小三種類型，以滿足市場需要。需求改了，怎麼辦？原先我沒預留要創造大、中、小等類型的筆的接口啊！如果我改動了Pen類，增加了純虛函數，那麼對原先的RedPen、BluePen等勢必會造成影響。爲了改動不太大，我決定爲RedPen、BluePen、Black等創建繼承體系，即：
就這樣，我創建出了大中小、顏色可以爲紅藍黑的筆了。如果以後Pen還要增加什麼特性，那麼類的個數會呈現指數性的增長了，繼承深度會加深，類會爆炸。
有什麼辦法能避免這樣的事情發生呢？我們可以這麼做：用組合替代繼承。在Pen類中，drow()是作爲虛函數存在的，任何繼承了Pen類的子類都要去重載實現這個函數。我們可以換種思路：在類Pen中增加成員Color抽象類，然後讓drow()作爲普通函數存在，在函數中調用 color->drow()。如下圖：
那麼新增顏色就會變成這樣：
注意到沒有，Pen類和Red、Blue、Black的關係是如此得薄弱，完全是外界關聯起來的，耦合度非常低，當Pen類發生改變時，即使發生繼承，對Color這個繼承樹的影響基本是沒有的，非常符合開源閉合原則，也就是我上面說的抽象A類與A類的成員抽象B類的實例化實現徹底地解耦。這就是bridge模式的實現。
若此時客戶要求我爲Pen類增加大中小三種類型，我可以有兩種選擇，一是用繼承；二是繼續用bridge模式。爲了實現徹底地解耦，我再次選擇bridge模式，我在Pen類中增加抽象Size類。
模型十分精簡，且耦合性極低，類的繼承深度減少、數目急劇減少。這就是bridge模式帶來的好處。
Bridge模式使用組合的方式將抽象和實現徹底地解耦，這樣的好處是抽象和實現可以分別獨立地變化，系統的耦合性也得到了很好的降低。