引言
在項目開發中，我們會遇到這樣的一種場景：某些類型由于自身的邏輯，往往具有兩個或多個維度的變化，比如說大話設計模式書中所說的手機，它有兩個變化的維度：一是手機的品牌，可能有三星、蘋果等；二是手機上的軟件，可能有QQ、微信等。如何應對這種“多維度的變化”？怎樣利用面向對象的技術來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復雜度？這就是本章橋接模式所要解決的問題。
何為橋接模式？
橋接模式的目的是把抽象層次結構從其實現中分離出來，使其能夠獨立變更。抽象層定義了供客戶端使用的上層的抽象接口。實現層定義了供抽象層使用的底層接口。實現類的引用被封裝于抽象層的實例中，橋接就形成。（與外觀模式有一定的相似之處）。
橋接模式：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
橋接模式的實例應用
比如有一家電視機制造商，他們生產的每臺電視都帶一個遙控器，用戶可以用遙控器進行頻道切換之類的操作。在這里遙控器是控制電視機的接口，如果每個電視機型號需要一個專用的遙控器，那么單是遙控器就會導致設計激增。不過，每個遙控器都有些功能是各種型號電視機共有的，比如切換頻道、調節音量和電源開關。而且每臺電視機都應該能夠通過基本命令接口，響應遙控器發來的這些命令。我們可以把遙控器邏輯同實際的電視機型號分離開來。這樣電視機型號的改變就不會對遙控器的設計有任何的影響。遙控器的同一個設計可以被復用和擴展，而不會影響其他電視機型號。如下圖所示：
AbstractRemoteControl是定義了供客戶端使用的上層接口的父接口。它有一個對TVProtocol視力的引用，TVProtocol定義了實現類的接口。這個接口不必跟AbstractRemoteControl的接口一致，其實兩個接口可以完全不同。TVProtocol的接口提供基本的操作，而AbstractRemoteControl的上層操作基于這些基本操作。當客戶端向AbstractRemoteControl的實例發送operation消息時，這個方法向imp發送operationImp消息，底下的實際由TVA或TVB將作出響應并接受任務。
因此想要往系統中添加新的TVProtocol時，所要做的只是為TVProtocol創建一個新的實現類，響應operationImp消息并在其中執行任何具體的操作。不過，這對AbstractRemoteControl方面不會有任何影響。同樣，如果想修改AbstractRemoteControl的接口或者創建更細化的AbstractRemoteControl類，也不會影響橋接的另一頭。
來看下具體的代碼實現，先看下抽象部分的代碼實現，AbstractRemoteControl代碼如下：
復制代碼 代碼如下:
#import <Foundation/Foundation.h>
#import "TVProtocol.h"
@interface AbstractRemoteControl : NSObject
@property (nonatomic, weak) id<TVProtocol> tvProtocol;
- (void)detectTVFunction;
@end
復制代碼 代碼如下:
#import "AbstractRemoteControl.h"
@implementation AbstractRemoteControl
- (void)detectTVFunction {
NSLog(@"檢測電視機具備的功能，由子類來進行實現");
}
@end
在AbstractRemoteControl類中保持了對TVProtocol實例對象的引用，定義了供客戶端使用的上層抽象接口detectTVFunction，而這個方法的具體實現則由其子類去實現，ConcreteRemoteControl代碼如下：
復制代碼 代碼如下:
#import "AbstractRemoteControl.h"
@interface ConcreteRemoteControl : AbstractRemoteControl
// 重寫該方法
- (void)detectTVFunction;
@end
復制代碼 代碼如下:
#import "ConcreteRemoteControl.h"
@implementation ConcreteRemoteControl
- (void)detectTVFunction {
[self.tvProtocol switchChannel];
[self.tvProtocol adjustVolume];
[self.tvProtocol powerSwitch];
}
@end
從這里我們可以看出，當客戶端向ConcreteRemoteControl的實例發送detectTVFunction消息時，這個方法向TVProtocol發送switchChannel、adjustVolume、powerSwitch三個消息，TVA或TVB將作出響應并接受任務。至此，抽象部分代碼已經完成了，接著看下實現部分的代碼，TVProtocol代碼如下：
復制代碼 代碼如下:
#import <Foundation/Foundation.h>
@protocol TVProtocol <NSObject>
@required
- (void)switchChannel; // 切換頻道
- (void)adjustVolume; // 調節音量
- (void)powerSwitch; // 電源開關
@end
這就是一個協議，協議里面定義了三個方法，以后在創建電視機實例的時候，就必須遵守該協議，從而保證了電視機具有相同的功能。AbstractTV的代碼如下：
#import <Foundation/Foundation.h>
#import "TVProtocol.h"
@interface AbstractTV : NSObject <TVProtocol>
@end
復制代碼 代碼如下:
#import "AbstractTV.h"
@implementation AbstractTV
- (void)switchChannel {
NSLog(@"切換頻道，由具體的子類來實現");
}
- (void)adjustVolume {
NSLog(@"調節音量，由具體的子類來實現");
}
- (void)powerSwitch {
NSLog(@"電源開關，由具體的子類來實現");
}
@end
TVA的代碼如下：
復制代碼 代碼如下:
#import "AbstractTV.h"
@interface TVA : AbstractTV
// 重寫這三個方法
- (void)switchChannel;
- (void)adjustVolume;
- (void)powerSwitch;
@end
復制代碼 代碼如下:
#import "TVA.h"
@implementation TVA
- (void)switchChannel {
NSLog(@"電視機A 具備了切換頻道的功能");
}
- (void)adjustVolume {
NSLog(@"電視機A 具備了調節音量的功能");
}
- (void)powerSwitch {
NSLog(@"電視機A 具備了電源開關的功能");
}
@end
TVB的代碼如下：
復制代碼 代碼如下:
#import "AbstractTV.h"
@interface TVB : AbstractTV
// 重寫這三個方法
- (void)switchChannel;
- (void)adjustVolume;
- (void)powerSwitch;
@end
復制代碼 代碼如下:
#import "TVB.h"
@implementation TVB
- (void)switchChannel {
NSLog(@"電視機B 具備了切換頻道的功能");
}
- (void)adjustVolume {
NSLog(@"電視機B 具備了調節音量的功能");
}
- (void)powerSwitch {
NSLog(@"電視機B 具備了電源開關的功能");
}
@end
到這里，橋接模式代碼已經完成了，在客戶端該怎么去應用呢？我們通過下面的客戶端代碼來說明，如下：
復制代碼 代碼如下:
#import "ViewController.h"
#import "AbstractRemoteControl.h"
#import "ConcreteRemoteControl.h"
#import "TVProtocol.h"
#import "AbstractTV.h"
#import "TVA.h"
#import "TVB.h"
typedef id<TVProtocol> TVProtocol; //在這里要進行一下轉換聲明,否則類中不能識別TVProtocol.
@interface ViewController ()
@end
復制代碼 代碼如下:
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
AbstractRemoteControl *remoteControl = [[ConcreteRemoteControl alloc] init];
TVProtocol tvProtocol = [[TVA alloc] init];
remoteControl.tvProtocol = tvProtocol;
[remoteControl detectTVFunction];
NSLog(@"http:///////////////////////////////");
tvProtocol = [[TVB alloc] init];
remoteControl.tvProtocol = tvProtocol;
[remoteControl detectTVFunction];
/**
* 橋接模式：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
* 在本例中，AbstractRemoteControl是抽象部分，TVProtocol是其實現部分。
*/
}
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
@end
日志輸出如下：2015-09-01 22:59:06.295 Bridge[16464:703747] 電視機A 具備了切換頻道的功能2015-09-01 22:59:06.295 Bridge[16464:703747] 電視機A 具備了調節音量的功能2015-09-01 22:59:06.296 Bridge[16464:703747] 電視機A 具備了電源開關的功能2015-09-01 22:59:06.296 Bridge[16464:703747] ///////////////////////////////2015-09-01 22:59:06.296 Bridge[16464:703747] 電視機B 具備了切換頻道的功能2015-09-01 22:59:06.296 Bridge[16464:703747] 電視機B 具備了調節音量的功能2015-09-01 22:59:06.296 Bridge[16464:703747] 電視機B 具備了電源開關的功能
通過橋接模式的應用，我們可以把抽象部分與實現部分分離，使它們都可以獨立的變化。比如在本例中，對AbstractRemoteControl的修改，不會影響到TVProtocol。同樣對TVProtocol的修改，也不會影響AbstractRemoteControl。這正是橋接模式帶給我們的便利性。
小結
總的來說，橋接模式的本質在于“分離抽象和實現”。
橋接模式的優點：
橋接模式使用聚合關系，解耦了抽象和實現之間固有的綁定關系，使得抽象和實現可以沿著各自的維度來變化。
提高了系統的可擴展性，可以獨立地對抽象部分和實現部分進行擴展。
可減少子類的個數，這個在前面講手機示例的時候進行分析了。
橋接模式的缺點：
橋接模式的引入會增加系統的理解與設計難度，由于聚合關系建立在抽象層，要求開發者針對抽象進行設計與編程。
橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。
適用場景
通過優缺點的分析，我們可以在如下的情形下使用橋接模式：
不想在抽象與其實現之間形成固定的綁定關系；
抽象及其實現都應可以通過子類化獨立進行擴展；
對抽象的實現進行修改不應影響客戶端代碼；
如果每個實現需要額外的子類以細化抽象，則說明有必要把它們分成兩個部分；
想在帶有不同抽象接口的多個對象之間共享一個實現。
