在項目開發(fā)中，我們經(jīng)常會遇到這樣的場景：某些類型由于自身的邏輯，往往具有兩個或多個維度的變化，比如手機(jī)，它有兩個變化的維度：一是手機(jī)品牌，可能有三星、蘋果等；二是手機(jī)上的軟件，可能有QQ、微信等。為了應(yīng)對這種“多維度的變化”，我們需要橋接模式來利用面向?qū)ο蟮募夹g(shù)來使得該類型能輕松的沿著多個方向進(jìn)行變化，而又不引入額外的復(fù)雜度。
1. 何為橋接模式
定義：將抽象部分與它的實現(xiàn)部分分離，使他們都可以獨立地變化。
比如上面那個例子：假設(shè)有一個系統(tǒng)，它可以使用多種方式來進(jìn)行分類，并且每一種分類都有可能變化，那么就把這些分類方式分離出來讓他們獨立的變化，以減少他們之間的耦合。
橋接模式的結(jié)構(gòu)圖如圖1-1所示：
Abstraction：定義中所說的抽象部分，通常在這個對象里面，要維護(hù)一個實現(xiàn)部分的對象引用，在抽象對象里面的方法，需要調(diào)用實現(xiàn)部分的對象來完成。這個對象里面的方法，通常都是跟具體的業(yè)務(wù)相關(guān)的方法。在上面手機(jī)的例子中，可以理解為手機(jī)品牌接口；
Implementor：定義中所說的實現(xiàn)部分，這個接口不用和Abstraction里面的方法一致，通常是由Implementor接口提供基本的操作，而Abstraction里面定義的是基于這些基本操作的業(yè)務(wù)方法，也就是說Abstraction定義了基于這些基本操作的較高層次的操作。在上面手機(jī)的例子中，可以理解為手機(jī)軟件接口(也可以是類)；
RefinedAbstraction：抽象部分的具體實現(xiàn)，通常在這個對象里面，定義跟實際業(yè)務(wù)相關(guān)的方法，這些方法的實現(xiàn)通常會使用Abstraction中定義的方法，也可能需要調(diào)用實現(xiàn)部分的對象來完成。在上面手機(jī)的例子中，可以理解為具體的手機(jī)品牌，它實現(xiàn)了Abstraction接口；
ConcreteImplementatorA：實現(xiàn)部分的具體實現(xiàn)，在上面手機(jī)的例子中，可以理解為具體的手機(jī)軟件，它實現(xiàn)了(或繼承了) Implementor。
2. 情景設(shè)置
我們依然采用上面手機(jī)的例子。手機(jī)這個例子用橋接模式實現(xiàn)的結(jié)構(gòu)圖如圖2-1所示：
從上面的結(jié)構(gòu)圖中我們可以看出橋接模式的優(yōu)點：它把抽象部分從實現(xiàn)部分中分離出來了，使得兩部分能夠獨立變更。這樣，添加新的RefinedAbstraction(抽象部分的具體實現(xiàn))，對Implementor(實現(xiàn)部分)不會有任何影響；同樣，添加新的ConcreteImplementatorC(實現(xiàn)部分的具體實現(xiàn))，也能做到不影響Abstraction(抽象部分)。
假設(shè)不使用橋接模式，我們可能做出的結(jié)構(gòu)圖有下面兩種：
（1）按品牌分類，如圖2-2所示：
（2）按軟件分類，如圖2-3所示：
當(dāng)我們增加一個手機(jī)品牌HTC，按照品牌分類的話我們需要增加手機(jī)品牌類HTC，還需要增加兩個手機(jī)軟件類HTC的QQ、HTC的微信；同樣，如果需要增加一個手機(jī)軟件，那么按照手機(jī)軟件分類的話，我們也是需要增加三個類。當(dāng)我們需要增加更多的手機(jī)品牌和手機(jī)軟件時，我們會發(fā)現(xiàn)類會越來越多，以致無法維護(hù)。另外，采用繼承的方式，子類和父類之間的耦合度是很高的，以至于父類中的任何變化必然會導(dǎo)致子類發(fā)生變化。這種依賴關(guān)系限制了靈活性并最終限制了復(fù)用性。
3. 代碼實現(xiàn)
這里還是繼續(xù)抽象工廠模式中的應(yīng)用場景：繪圖有兩個變化維度，一是工具，可以用HTML5、OWC等；另一個是圖形的種類，我們可能需要繪制餅狀圖、線形圖等。下面給出采用橋接模式實現(xiàn)的結(jié)構(gòu)圖，如圖3-1所示：
（1）Chart.h
@protocol Chart <NSObject>
- (void)draw;
@end
（2）LineChart.m(PieChart.m類似)，實現(xiàn)了Chart協(xié)議：
- (void)draw
{
NSLog(@"繪制線形圖");
}
（3）Tool.h，一個協(xié)議，這個協(xié)議里面定義了一個Chart類型的屬性和一個繪圖的方法。
#import "Chart.h"
@protocol Tool <NSObject>
@property (nonatomic,assign) id<Chart> chart;
- (void)drawing;
@end
（4）HTML5.m(Owc.m類似)，實現(xiàn)了Tool協(xié)議：
@synthesize chart = _chart;
- (void)drawing
{
NSLog(@"HTML5 繪圖開始......");
[_chart draw];
NSLog(@"HTML5 繪圖結(jié)束......");
}
（5）客戶端調(diào)用
id<Tool> tool = [[NSClassFromString(@"HTML5") alloc] init];
tool.chart = [[NSClassFromString(@"LineChart") alloc] init];
[tool drawing];
橋接模式解決了兩維或多維變化的問題，結(jié)構(gòu)圖和上面的示例所講述的都是兩維，那么多維變化的又是怎么樣的呢？假設(shè)現(xiàn)在繪圖這個功能，需要支持不同的平臺，比如說要支持Windows平臺和Mac平臺，那么結(jié)構(gòu)圖又是怎么樣的？下面給出這種情況下的橋接模式的結(jié)構(gòu)圖，如圖3-2所示：
4. 小結(jié)
4.1 橋接模式的優(yōu)點
（1）橋接模式使用聚合關(guān)系，解耦了抽象和實現(xiàn)之間固有的綁定關(guān)系，使得抽象和實現(xiàn)可以沿著各自的維度來變化。
（2）提高了系統(tǒng)的可擴(kuò)展性，可以獨立地對抽象部分和實現(xiàn)部分進(jìn)行擴(kuò)展。
（3）可減少子類的個數(shù)，這個在前面講手機(jī)示例的時候進(jìn)行分析了。
4.2 橋接模式的缺點
（1）橋接模式的引入會增加系統(tǒng)的理解與設(shè)計難度，由于聚合關(guān)系建立在抽象層，要求開發(fā)者針對抽象進(jìn)行設(shè)計與編程。
（2）橋接模式要求正確識別出系統(tǒng)中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。
4.3 橋接模式的使用的場景
通過優(yōu)缺點的分析，我們可以在如下的場景下使用橋接模式：
（1）不想在抽象與其實現(xiàn)之間形成固定的綁定關(guān)系；
（2）抽象及其實現(xiàn)都應(yīng)可以通過子類化獨立進(jìn)行擴(kuò)展；
（3）對抽象的實現(xiàn)進(jìn)行修改不應(yīng)影響客戶端代碼；
（4）如果每個實現(xiàn)需要額外的子類以細(xì)化抽象，則說明有必要把它們分成兩個部分；
（5）想在帶有不同抽象接口的多個對象之間共享一個實現(xiàn)。
總的來說，橋接模式的本質(zhì)在于分離抽象和實現(xiàn)。
