桥梁模式和适配器模式的区别
共同點：橋接和適配器都是讓兩個東西配合工作
不同點：出發點不同。
?????????適配器：改變已有的兩個接口，讓他們相容。
??????? ?橋接模式：分離抽象化和實現，使兩者的接口可以不同，目的是分離。
所以說，如果你拿到兩個已有模塊，想讓他們同時工作，那么你使用的適配器。
如果你還什么都沒有，但是想分開實現，那么橋接是一個選擇。
橋接是先有橋，才有兩端的東西
適配是先有兩邊的東西，才有適配器
橋接是在橋好了之后，兩邊的東西還可以變化。
橋梁模式
抽象與實現
抽象不應該依賴于實現細節，實現細節應該依賴于抽象。
問題在于如果抽象B由于固有的原因，本身并不穩定，也有可能變化，怎么辦？
?
舉例來說
假如我們需要開發一個同時支持PC和手機的坦克游戲，游戲在PC和手機上功能都一樣，都有同樣的類型，面臨同樣的功能需求變化，比如坦克可能有很多種不同的型號：T50，T75，T90……
對于其中的坦克設計，我們可能很容易設計出來一個Tank的抽象基類，然后各種不同型號的Tank繼承自該類;
?
另外的變化原因
但是PC和手機上的圖形繪制、聲效、操作等實現完全不同……因此對于各種型號的坦克，都要提供各種不同平臺上的坦克實現：
這樣的設計會帶來很多問題：有很多重復代碼，類的結構過于復雜，難以維護，最致命的是引入任何新平臺，比如在TV上的Tank游戲，都會讓整個類層級結構復雜化。
?
動機（Motivation）
思考上述問題的癥結：事實上由于Tank類型的固有邏輯，使得Tank類型具有了兩個變化的維度——一個變化的維度為“平臺的變化”，一個變化的維度為“型號的變化”。
如何應對這種“多維度的變化”？如何利用面向對象技術來使得Tank類型可以輕松地沿著“平臺”和“型號”兩個方向變化，而不引入額外的復雜度？
?
意圖（Intent）
將抽象部分與實現部分分離，使它們都可以獨立地變化。
——《設計模式》GoF
橋模式不能只是認為是抽象和實現的分離，它其實并不僅限于此。如下面的例子，兩個都是抽象的部分。更確切的理解，應該是將一個事物中多個維度的變化分離。
?對于這種在多個維度上都會有變化或擴充需求的項目來說，可以考慮引入橋接模式。或許你會說，不管是什么場景，不管什么模式，都可以是抽象場景的一個子類，但是，如果這樣的話，4個場景和3種模式就會產生12個子類，而10個場景5種模式就會有50個子類。一味進行繼承并不是什么好方法，橋接模式的思想是把繼承轉化為組合，把乘法(10*5=50)轉化為加法(10+5=15)。?
例說Bridge應用
版本一?
先寫各種不同的坦克型號類T50、T75等繼承自Tank，然后再讓各種平臺的坦克繼承自對應型號的類，如PCT50，PCT75繼承自T50等。這樣設計可能會有很多重復的代碼，例PCT50和PCT75。
?
版本二
因為平臺和坦克型號都是變化，所以我們把平臺的變化作為屬性放到基抽象類中。
平臺實現類
下面是整個代碼的骨架
Tank的型號，和Tank的平臺都繼承自各自的抽象類，因此它們的變化都不會影響到對方。而它們之間的關聯，我們使用組合的方式，把平臺類放到Tank類中作為屬性。這再次體現了組合優先于繼承的思想。多繼承的方法就是版本一的代碼，這種方式子類和父類的關系太緊，造成緊耦合。
這就是橋模式，把變化引出了基類Tank，使得Tank僅守與型號的變化。
?
應用程序
在環境交互中使用的都是抽象類，并且把平臺實現隱藏，在應用程序中new平臺的方式也可以根據情況用Singleton模式或者Abstract Factory模式等實現。
?
結構（Structure）
其中imp的地方就是一個組合。Abstraction就是我們之前例子中的Tank，它的子類RefinedAbstraction就是T50等型號。Implementor是TankPlatformImplementation類，ConcreteImplementorA和ConcreteImplementorB分別是PCTankImplementation和MobileTankImplementation。
整個設計模式的關鍵就是組合的使用。
?
Bridge模式的幾個要點
Bridge模式使用“對象間的組合關系”解耦了抽象和實現之間固有的綁定關系，使得抽象（Tank的型號）和實現（不同的平臺）可以沿著格子的維度來變化。
所謂抽象和實現沿著各自維度的變化，即“子類化”它們（比如不同的Tank型號子類，和不同的平臺子類），得到各個子類之后，便可以任意組合它們，從而獲得不同平臺上的不同型號。
Bridge模式有時候類似于多繼承方案，但是多繼承方案往往違背單一職責原則（即一個類只有一個變化的原因），復用性比較差。Bridge模式是比多繼承方案更好的解決方法。
下面是針對上面的例子，多繼承接口的一種寫法：?
這樣PCT50既需要寫T50的實現，又要寫Platform的實現，它把型號和平臺的變化都引入了PCT50。這樣就把兩個本不該扭在一起的事務扭在了一起，這樣的設計更加糟糕，而且也違背了類的單一職責原則。
Bridge模式的應用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度，但是某個方向的變化維度并不劇烈——換言之兩個變化不會導致縱橫交錯的結果，并不一定要使用Bridge模式。
?
橋模式并不同于適配器模式，適配器模式其實是一個事后諸葛亮，當發現以前的東西不適用了才去做一個彌補的措施。橋模式相對來說所做的改變比適配器模式早，它可以適用于有兩個甚至兩個以上維度的變化。
總結
以上是生活随笔為你收集整理的桥梁模式和适配器模式的区别的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 10 款基于 jQuery 的切换效果插
- 下一篇： CXF发布webservice