設計模式之——橋接（Bridge）和策略（strategy）

之所以把這兩個放在一起，是因為他們很相似，但又是完全不同的

先來看看Bridge模式

1）如果客戶給了一個需求，故我們實現了類A

2）過了幾天客戶說這個東東需要有兩種演算法，故我們派生出 A0, A1

3）然後又過了幾天，客戶又提出要求說要在不同的作業系統下實現，故我們派生出類A0a, A0b, A1a, A1b

這樣我們需要不停的派生，不停的改

Bridge模式就是解決這個問題的， 對象和行為都要不停的改變， 把對象和行為類分開，單獨演化，在對象類中包含行為類的變數，這樣就可以隨意組合，其類圖關係如下

其中，Abstraction和 AbstractionImp分別是類和行為的抽象介面，即基類。Bridge用組合而不是繼續的方式來處理問題，這是符合物件導向的思想的，能有組合的盡量不用繼承，這樣使得代碼更靈活。

有一篇文章對Bridge講得特別好，http://www.blogjava.net/lijiajia418/archive/2006/09/18/70268.html

另外說點Bridge和visitor的相似和不同點：

我剛開始看的時候覺得兩個模式幾乎就是一樣的，都是把元素和行為進行分離，然後可以獨立演變和組合。但其實他們還是有很大的不同的

1）對於Bridge模式，Abstraction裡面要包含AbstractionImp的指標；而對於Visitor而言，Element並不包含Visitor的指標。從這一點上看，Bridge描述的元素和行為的內聚性更高。

2）Bridge的結構使得類的行為與類相對獨立，而Visitor則是使得類的某個行為的不同實現之間可以相互獨立，並且vistor的行為並不一定屬於其處理的對象所應有的行為。Bridge是要解決抽象類別與自身行為實現的分離，Vistor要解決的是將對抽象類別與其各種外在訪問行為的分離。

3) Visitor雖然也有元素和行為分離的思想在裡面，但這個模式最重要的是雙派發機制，可以用類似emp->accpt(pvisitor)的統一介面來實現雙重派發，那麼這樣就可以把代碼寫得很簡單，特別是在迴圈裡面，沒有很多的條件判斷，這也是它最大的用處，但是這是建立在元素類穩定，不需要增加的情況下的，如果具體的元素類不穩定，要經常增加，那麼所有的具體visitor類都要修改，是不符合OCP的；而Bridge模式的應用情境根本不是這樣的，它要解決的元素和行為可以單獨演變

我們再來看Strategy模式

其定義也很簡單，定義演算法簇，分別封裝起來，讓他們可以動態相互替換，使使用者可以使用不同的演算法來實現。它的類圖和Bridge非常類似

同樣，Context也會包含一個指向Strategy對象的指標，使得Context可以使用不同的策略演算法，甚至Context也可以有子類，使得類圖和Bridge完全一樣。

實際上所有模式可以只分為類模式和對象模式兩種，類模式是用繼承而對象模式是用委託 ，Bridge模式和Strategy模式相似就是因為他們都將任務委託給了另外一個介面的具體實現。

現在看看他們的區別，搞清楚了區別，也就真正的搞清了這兩個設計模式，參考了網上一些比較經典的說明：

一，在形式上，兩者還是有一定區別的，對比兩幅結構圖，我們可以發現，在橋接模式中不僅行為具有變化 ，而且Abstraction也可以發生變化，而且兩者的變化是完全獨立的，它們僅僅通過Abstraction與 Implementor之間的關係聯絡起來。而在策略模式中，並不考慮Context的變化，只有演算法的可替代性，當然我們說過，其實Context也是可以子類的，這樣他們再類圖上就是一樣的了，但是對於Strategy而言，Context的變化並不是它關心的重點。

二，它們最重要的區別就在於Strategy裡面紅色的幾個詞，Strategy主要是封裝了演算法，使得演算法可以動態替換，也就是說，Context中指向Strategy對象的指標的值是可以動態設定的，一般會有一個方法SetStrategy類似的方法在Context裡面，所以它是一個行為模式，描述的是行為的變化；而Bridge模式中，指向行為是指標是不能改變的，它主要是要表達一個系統中的元素和行為可以單獨變化，隨意的組合，但一旦組合上之後是不變的，更多的是描述系統的結構，所以是一種結構模式。 很多模式的實現上都很相似，但它們的應用情境是不一樣的，這才是設計模式最重要的內容，模式只是一個實現工具而已。