生活中的場景:
就拿汽車在路上行駛的來說葛圃。即有小汽車又有公共汽車诬烹，它們都不但能在市區(qū)中的公路上行駛型檀，也能在高速公路上行駛冗尤。這你會發(fā)現(xiàn)，對于交通工具（汽車）有不同的類型胀溺，然而它們所行駛的環(huán)境（路）也在變化裂七，在軟件系統(tǒng)中就要適應(yīng)兩個方面的變化？怎樣實現(xiàn)才能應(yīng)對這種變化呢仓坞？
概述:
在軟件系統(tǒng)中背零，某些類型由于自身的邏輯，它具有兩個或多個維度的變化无埃，那么如何應(yīng)對這種“多維度的變化”徙瓶？如何利用面向?qū)ο蟮募夹g(shù)來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復(fù)雜度嫉称？這就要使用Bridge模式侦镇。橋接模式的關(guān)鍵 是：將抽象部分與實現(xiàn)部分分離，使它們都可以獨立的變化织阅。
如下圖所示
下面 我們 將通過?DEMO下載地址? 來剖析 為什么需要使用橋接模式以及怎么解決這些問題壳繁。
傳統(tǒng)做法
通過類的繼承來做。 將上面的列子如下圖所示
在DEMO 中如下圖說示：
在主要 控制器 ViewController 中：
- (void)badExample{
//
CarStreet*carStreet = [[CarStreetalloc]init];
[carStreetrun];
//
BusStreet*busStreet = [[BusStreetalloc]init];
[busStreetrun];
}
正如DEMO中所說：其實反過來不論 我們以 Car 為例 分出 bus autoCar又分出在 高速公路 上的 bus 和 autoCar和 在街道上的bus 和 autoCar
和我們以 Road 為例 通過繼承 分出的是類似的
現(xiàn)在的問題是：
但是我們說這樣的設(shè)計是脆弱的，仔細分析就可以發(fā)現(xiàn)氮趋，它還是存在很多問題伍派，首先它在遵循開放-封閉原則的同時，違背了類的單一職責原則剩胁，即一個類只有一個引起它變化的原因，而這里引起變化的原因卻有兩個祥国，即路類型的變化和汽車類型的變化昵观；其次是重復(fù)代碼會很多，不同的汽車在不同的路上行駛也會有一部分的代碼是相同的舌稀；再次是類的結(jié)構(gòu)過于復(fù)雜啊犬，繼承關(guān)系太多，難于維護壁查，最后最致命的一點是擴展性太差觉至。如果變化沿著汽車的類型和不同的道路兩個方向變化，我們會看到這個類的結(jié)構(gòu)會迅速的變龐大睡腿。
比如 有 10 種道路 和 10 種類型的車 那么有 10*10 = 100 個具體的類
橋接模式的做法
在DEMO 中 對應(yīng)
- (void)solveBadExample
{
AbstractRoad*road1 = [[ConcreteSpeedWayalloc]init];
road1.car= [[ConcreateCaralloc]init];
[road1run];
AbstractRoad*road2 = [[ConcreteSpeedWayalloc]init];
road2.car= [[ConcreateBusalloc]init];
[road2run];
}
可以看到语御，通過對象組合的方式，Bridge 模式把兩個角色之間的繼承關(guān)系改為了耦合的關(guān)系席怪，從而使這兩者可以從容自若的各自獨立的變化应闯，這也是Bridge模式的本意。
這樣增加了客戶程序與路與汽車的耦合挂捻。其實這樣的擔心是沒有必要的碉纺，因為這種耦合性是由于對象的創(chuàng)建所帶來的，完全可以用創(chuàng)建型模式去解決刻撒。在應(yīng)用時結(jié)合創(chuàng)建型設(shè)計模式來處理具體的問題码荔。
關(guān)鍵的代碼是 AbstractRoad 里有個 AbstractCar 這樣的對應(yīng)關(guān)系
可以看出來 如果 Road和 Car 是 需要的類的總數(shù) 是 N+M 的關(guān)系 而壞的例子中是 N*M 的類的總數(shù)
橋接模式（Bridge）來做(多維度變化);
結(jié)合上面的例子,增加一個維度"人",不同的人開著不同的汽車在不同的路上行駛(三個維度);
結(jié)合上面增加一個類"人",并重新調(diào)用.
效果及實現(xiàn)要點：
1．Bridge模式使用“對象間的組合關(guān)系”解耦了抽象和實現(xiàn)之間固有的綁定關(guān)系馆截，使得抽象和實現(xiàn)可以沿著各自的維度來變化。
2．所謂抽象和實現(xiàn)沿著各自維度的變化，即“子類化”它們亿傅，得到各個子類之后，便可以任意它們圾浅，從而獲得不同路上的不同汽車健民。
3．Bridge模式有時候類似于多繼承方案，但是多繼承方案往往違背了類的單一職責原則（即一個類只有一個變化的原因）胎撇，復(fù)用性比較差介粘。Bridge模式是比多繼承方案更好的解決方法。
4．Bridge模式的應(yīng)用一般在“兩個非常強的變化維度”晚树，有時候即使有兩個變化的維度姻采，但是某個方向的變化維度并不劇烈——換言之兩個變化不會導(dǎo)致縱橫交錯的結(jié)果，并不一定要使用Bridge模式爵憎。
適用性：
在以下的情況下應(yīng)當使用橋梁模式：
1．如果一個系統(tǒng)需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性慨亲，避免在兩個層次之間建立靜態(tài)的聯(lián)系婚瓜。
2．設(shè)計要求實現(xiàn)化角色的任何改變不應(yī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)新功能增加的需要，當我們把描述新功能的類封裝到基類的對象里面時鳄厌，就得到了所需要的子類對象荞胡，這些描述新功能的類通過組合可以實現(xiàn)很多的功能組合 .
橋接模式：
橋接模式則把原來的基類的實現(xiàn)化細節(jié)抽象出來，在構(gòu)造到一個實現(xiàn)化的結(jié)構(gòu)中了嚎，然后再把原來的基類改造成一個抽象化的等級結(jié)構(gòu)泪漂，這樣就可以實現(xiàn)系統(tǒng)在多個維度上的獨立變化 。
