由于實際的需要拳球，某個類具有兩個或兩個以上的維度變化扔涧，如果利用繼承將每種可能的變化情況都定義成一個類集畅，一是會導(dǎo)致類膨脹的問題近弟，二是以后不太好維護和并且違背類的設(shè)計原則。那么面對這種情況挺智，類改如何設(shè)計呢祷愉？這就是本文所要講到的橋接模式。
簡單的講赦颇，橋接模式是指：將抽象和行為劃分開來二鳄，從而將各個可能變化的維度分離開來，各自獨立成一個類媒怯，但是能夠動態(tài)的組合订讼。
貌似有點抽象，下面通過一個簡單的例子來理解橋接模式扇苞。
我們可以通過Email發(fā)送信息欺殿，也可以手段短信發(fā)送信息（當(dāng)然，以后很可能新增電報發(fā)信息等等）鳖敷，同時脖苏，根據(jù)信息的緊急程度，還可以分為緊急和普通（當(dāng)然以后可能新增不緊急定踱、特別緊急等等）棍潘，橋接模式中類該怎么設(shè)計呢？
1.首先抽離出兩個變化的維度：信息類型和和發(fā)信息的方式：
發(fā)信息接口：
1interfaceSendMsgInterface {23publicvoidsendMsg();45}
信息類型的抽象類：
1abstractclassMsg {23privateSendMsgInterface smi;45publicMsg(SendMsgInterface smi) {6this.smi =smi;7}89publicabstractvoidsend();1011}
2.定義Emil發(fā)送方式類和Sms方式發(fā)送類：
1classEmailSendMsgimplementsSendMsgInterface{23@Override4publicvoidsendMsg() {5System.out.println("Email 方式發(fā)送");6}78}
1classSmsSendMsgimplementsSendMsgInterface{23@Override4publicvoidsendMsg() {5System.out.println("Sms 方式發(fā)送");6}78}
3.定義緊急信息和普通信息類：
1classImportantMsgextendsMsg {23publicImportantMsg(SendMsgInterface smi) {4super(smi);5}67@Override8publicvoidsend() {9System.out.println("緊急信息");10}1112}
1classNormalMsgextendsMsg {23publicNormalMsg(SendMsgInterface smi) {4super(smi);5}67@Override8publicvoidsend() {9System.out.println("普通信息");10}1112}
4.客戶端測試：
publicclassBridgeTest {publicstaticvoidmain(String[] args) {//以手機短信發(fā)送發(fā)送緊急信息SendMsgInterface smdSendMsg =newSmsSendMsg();
Msg importantMsg=newImportantMsg(smdSendMsg);
importantMsg.send();
}
}
看崖媚，橋接模式對于多個維度的變化處理起來很有優(yōu)勢亦歉。
按照其他的模式定義，如外觀模式需要增加一個外觀類畅哑，代理模式需要增加一個代理類等肴楷，在如上的橋接模式設(shè)計中，其實Msg已經(jīng)隱含的作為橋接的父類敢课，當(dāng)然阶祭，設(shè)計模式是死的，人是活的直秆，其實也可以單獨定義出一個專門用于橋接目的的橋接類濒募。
生活中的一個例子:
就拿汽車在路上行駛的來說。即有小汽車又有公共汽車圾结，它們都不但能在市區(qū)中的公路上行駛瑰剃，也能在高速公路上行駛。這你會發(fā)現(xiàn)筝野，對于交通工具（汽車）有不同的類型晌姚，然而它們所行駛的環(huán)境（路）也在變化粤剧，在軟件系統(tǒng)中就要適應(yīng)兩個方面的變化？怎樣實現(xiàn)才能應(yīng)對這種變化呢挥唠？
概述:
在軟件系統(tǒng)中抵恋，某些類型由于自身的邏輯，它具有兩個或多個維度的變化宝磨，那么如何應(yīng)對這種“多維度的變化”弧关？如何利用面向?qū)ο蟮募夹g(shù)來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復(fù)雜度唤锉？這就要使用Bridge模式世囊。
意圖:
將抽象部分與實現(xiàn)部分分離，使它們都可以獨立的變化窿祥。
——《設(shè)計模式》GOF
結(jié)構(gòu)圖:
傳統(tǒng)的做法:
通過類繼承的方式來做上面的例子;
先看一下類結(jié)構(gòu)圖:
缺點:
但是我們說這樣的設(shè)計是脆弱的株憾，仔細分析就可以發(fā)現(xiàn)，它還是存在很多問題晒衩，首先它在遵循開放-封閉原則的同時嗤瞎，違背了類的單一職責(zé)原則，即一個類只有一個引起它變化的原因听系，而這里引起變化的原因卻有兩個猫胁，即路類型的變化和汽車類型的變化；其次是重復(fù)代碼會很多跛锌，不同的汽車在不同的路上行駛也會有一部分的代碼是相同的；再次是類的結(jié)構(gòu)過于復(fù)雜届惋，繼承關(guān)系太多髓帽，難于維護，最后最致命的一點是擴展性太差脑豹。如果變化沿著汽車的類型和不同的道路兩個方向變化郑藏，我們會看到這個類的結(jié)構(gòu)會迅速的變龐大。
應(yīng)用設(shè)計模式
橋接模式（Bridge）來做;
先看一下類結(jié)構(gòu)圖:
代碼實現(xiàn):
可以看到瘩欺，通過對象組合的方式必盖，Bridge 模式把兩個角色之間的繼承關(guān)系改為了耦合的關(guān)系，從而使這兩者可以從容自若的各自獨立的變化俱饿，這也是Bridge模式的本意歌粥。
這樣增加了客戶程序與路與汽車的耦合。其實這樣的擔(dān)心是沒有必要的拍埠，因為這種耦合性是由于對象的創(chuàng)建所帶來的失驶，完全可以用創(chuàng)建型模式去解決。在應(yīng)用時結(jié)合創(chuàng)建型設(shè)計模式來處理具體的問題枣购。
應(yīng)用設(shè)計模式:
橋接模式（Bridge）來做(多維度變化);
結(jié)合上面的例子,增加一個維度"人",不同的人開著不同的汽車在不同的路上行駛(三個維度);
結(jié)合上面增加一個類"人",并重新調(diào)用.
效果及實現(xiàn)要點：
1．Bridge模式使用“對象間的組合關(guān)系”解耦了抽象和實現(xiàn)之間固有的綁定關(guān)系嬉探，使得抽象和實現(xiàn)可以沿著各自的維度來變化擦耀。
2．所謂抽象和實現(xiàn)沿著各自維度的變化，即“子類化”它們涩堤，得到各個子類之后眷蜓，便可以任意它們，從而獲得不同路上的不同汽車胎围。
3．Bridge模式有時候類似于多繼承方案吁系，但是多繼承方案往往違背了類的單一職責(zé)原則（即一個類只有一個變化的原因），復(fù)用性比較差痊远。Bridge模式是比多繼承方案更好的解決方法垮抗。
4．Bridge模式的應(yīng)用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度碧聪，但是某個方向的變化維度并不劇烈——換言之兩個變化不會導(dǎo)致縱橫交錯的結(jié)果冒版，并不一定要使用Bridge模式。
適用性：
在以下的情況下應(yīng)當(dāng)使用橋梁模式：
1．如果一個系統(tǒng)需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性逞姿，避免在兩個層次之間建立靜態(tài)的聯(lián)系辞嗡。
2．設(shè)計要求實現(xiàn)化角色的任何改變不應(yīng)當(dāng)影響客戶端，或者說實現(xiàn)化角色的改變對客戶端是完全透明的滞造。
3．一個構(gòu)件有多于一個的抽象化角色和實現(xiàn)化角色续室，系統(tǒng)需要它們之間進行動態(tài)耦合。
4．雖然在系統(tǒng)中使用繼承是沒有問題的谒养，但是由于抽象化角色和具體化角色需要獨立變化挺狰，設(shè)計要求需要獨立管理這兩者。
總結(jié)：
Bridge模式是一個非常有用的模式买窟，也非常復(fù)雜丰泊，它很好的符合了開放-封閉原則和優(yōu)先使用對象，而不是繼承這兩個面向?qū)ο笤瓌t始绍。
橋接模式與裝飾的區(qū)別:
裝飾模式:
這兩個模式在一定程度上都是為了減少子類的數(shù)目瞳购，避免出現(xiàn)復(fù)雜的繼承關(guān)系。但是它們解決的方法卻各有不同亏推，裝飾模式把子類中比基類中多出來的部分放到單獨的類里面学赛，以適應(yīng)新功能增加的需要，當(dāng)我們把描述新功能的類封裝到基類的對象里面時吞杭，就得到了所需要的子類對象盏浇，這些描述新功能的類通過組合可以實現(xiàn)很多的功能組合 .
橋接模式：
橋接模式則把原來的基類的實現(xiàn)化細節(jié)抽象出來，在構(gòu)造到一個實現(xiàn)化的結(jié)構(gòu)中芽狗，然后再把原來的基類改造成一個抽象化的等級結(jié)構(gòu)缠捌，這樣就可以實現(xiàn)系統(tǒng)在多個維度上的獨立變化 。
