橋接模式（Bridge）-結構型模式
橋接模式是將抽象化與實現進行脫藕的一種模式，使一個類實例化和他的行為解耦合，讓他們可以有自己獨立的變化空間，而不會因為類行為過多依賴類本身或類本身被類行為牽制，帶來的變化受制的問題。這裡需要主意的是橋接模式是將類和類行為現實減弱耦合關聯並不一定要完全解耦合，當然如果可以的話完全解耦合的設計方案更優。
在設計時的運用請看下面的UML圖
在生活中我們有各種各樣的交通工具供我們使用，如果需要我們設計出這個交通工具和他們的基本使用，我們知道交通工具基本上分海陸空三種，每種工具的操作流程差異非常大，就是同類型的交通工具在操作上也有細微的差別，如果我們只抽象出一個交通工具的抽象類，我們需要依據交通工具的類型判斷他們的基礎操作，噢！天哪世界上那麼多的交通工具要寫多少的條件判斷，以後如果我要想加一種類型的交通工具就要更改原有設計，所以這是一種糟糕的設計！由於交通工具的實現和實體類的行為都在不停的變化，所以我們要盡量的把變化的地方封裝起來。這樣就引用到我們現在學習的橋接模式了，解耦合，類實現與類行為是橋接模式的拿手絕活。
我們來看看一個優化後的設計
首先： 我們抽象出類的實現接口和行為接口（IVehick，IRunHandle）
其次： 抽現出海陸空三種抽象的交通工具類和3中交通工具的基本操作類，並且抽象類實現部分包含抽現類行為，讓抽象類依賴與抽現類行為。
最後： 現在我們想要的3中交通工具類和他們的行為
讓我們回頭看看這個OOD設計是否合理，我們依據我們第二章的設計模式原則來判定
1. 是否符合開閉原則
我們在新增一種交通工具的時候只需要實現他們的類和行為即可。
答案：符合
2. 是否符合裡氏代換原則
不用多說了。
答案：符合
3. 是否符合依賴倒置原則
交通工具類依賴與交通工具操作抽象類
答案：符合
4. 是否符合接口隔離原則
IVehick，IRunHandle 一個接口負責管理實現一個類，一個接口負責管理類行為
如果原始設計的話IVehick接口可以包含IRunHandle接口這樣就緊耦合了
答案：符合
5. 是否符合抽象原則
答案：符合
6. 是否符合迪米特法則
答案：符合
總結 ：橋接模式
意圖：將抽現部分與他們的實現分離，使他們能夠獨立的變化
動機：
當一個抽象可能有多個實現（交通工具有海陸空3中實現）通常我們用繼承類協調他們，抽象類定義對該抽象的接口而集體的子類則用不同方式加以實現。但此方法有時不夠靈活。繼承機制將抽象部分與實現部分固定在一起，使得難以對抽象部分和實現部分獨立地進行修改、擴充和重用。
適用性：
l 不希望在抽象和它的實現部分之間有一個固定的綁定關系
l 類的抽象以及它的實現都應該可以通過生成子類的方法加以擴充。
l 對一個抽象的實現部分的修改應該對客戶不產生影響
結構：
參與者：
l Abstraction （Car, ship,airpalin）
l RefinedAbstraction (XianDai,BoYin747,HaiShenYouLun)
l Implementor (IRunHandle)
l ConcreteImplementor (CarHandle,ShipHandle,AirplainHandle)
Bridge模式的優點：
1. 分離接口以及實現部分
2. 提高可擴充性
3. 現在細節對用戶透明（可隱藏實現細節）
代碼：
