設計模式總結篇系列：橋接模式（Bridge）

在實際類設計過程中，有時會遇到此類情況：由于實際的需要，某個類具有兩個或兩個以上的次元變化，如果利用繼承将每種可能的變化情況都定義成一個類，一是會導緻類膨脹的問題，二是以後不太好維護和并且違背類的設計原則。那麼面對這種情況，類改如何設計呢？這就是本文所要講到的橋接模式。

簡單的講，橋接模式是指：将抽象和行為劃分開來，進而将各個可能變化的次元分離開來，各自獨立成一個類，但是能夠動态的組合。

貌似有點抽象，下面通過一個簡單的例子來了解橋接模式。

我們可以通過Email發送資訊，也可以手段短信發送資訊（當然，以後很可能新增電報發資訊等等），同時，根據資訊的緊急程度，還可以分為緊急和普通（當然以後可能新增不緊急、特别緊急等等），橋接模式中類該怎麼設計呢？

1.首先抽離出兩個變化的次元：資訊類型和和發資訊的方式：

發資訊接口：

資訊類型的抽象類：

2.定義Emil發送方式類和Sms方式發送類：

3.定義緊急資訊和普通資訊類：

4.用戶端測試：

看，橋接模式對于多個次元的變化處理起來很有優勢。

按照其他的模式定義，如外觀模式需要增加一個外觀類，代理模式需要增加一個代理類等，在如上的橋接模式設計中，其實Msg已經隐含的作為橋接的父類，當然，設計模式是死的，人是活的，其實也可以單獨定義出一個專門用于橋接目的的橋接類。