很多時(shí)候經(jīng)常容易把橋接模式和適配器模式弄混。那什么時(shí)候用橋接，什么時(shí)候用適配器呢 ？

共同點(diǎn)：橋接和適配器都是讓兩個(gè)東西配合工作
不同點(diǎn)：出發(fā)點(diǎn)不同。
?????????適配器：改變已有的兩個(gè)接口，讓他們相容。
??????? ?橋接模式：分離抽象化和實(shí)現(xiàn)，使兩者的接口可以不同，目的是分離。

所以說(shuō)，如果你拿到兩個(gè)已有模塊，想讓他們同時(shí)工作，那么你使用的適配器。
如果你還什么都沒有，但是想分開實(shí)現(xiàn)，那么橋接是一個(gè)選擇。

橋接是先有橋，才有兩端的東西
適配是先有兩邊的東西，才有適配器

橋接是在橋好了之后，兩邊的東西還可以變化。

橋梁模式

抽象與實(shí)現(xiàn)

抽象不應(yīng)該依賴于實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)應(yīng)該依賴于抽象。

問(wèn)題在于如果抽象B由于固有的原因，本身并不穩(wěn)定，也有可能變化，怎么辦？

?

舉例來(lái)說(shuō)

假如我們需要開發(fā)一個(gè)同時(shí)支持PC和手機(jī)的坦克游戲，游戲在PC和手機(jī)上功能都一樣，都有同樣的類型，面臨同樣的功能需求變化，比如坦克可能有很多種不同的型號(hào)：T50，T75，T90……

對(duì)于其中的坦克設(shè)計(jì)，我們可能很容易設(shè)計(jì)出來(lái)一個(gè)Tank的抽象基類，然后各種不同型號(hào)的Tank繼承自該類;

?

另外的變化原因

但是PC和手機(jī)上的圖形繪制、聲效、操作等實(shí)現(xiàn)完全不同……因此對(duì)于各種型號(hào)的坦克，都要提供各種不同平臺(tái)上的坦克實(shí)現(xiàn)：

這樣的設(shè)計(jì)會(huì)帶來(lái)很多問(wèn)題：有很多重復(fù)代碼，類的結(jié)構(gòu)過(guò)于復(fù)雜，難以維護(hù)，最致命的是引入任何新平臺(tái)，比如在TV上的Tank游戲，都會(huì)讓整個(gè)類層級(jí)結(jié)構(gòu)復(fù)雜化。

?

動(dòng)機(jī)（Motivation）

思考上述問(wèn)題的癥結(jié)：事實(shí)上由于Tank類型的固有邏輯，使得Tank類型具有了兩個(gè)變化的維度——一個(gè)變化的維度為“平臺(tái)的變化”，一個(gè)變化的維度為“型號(hào)的變化”。

如何應(yīng)對(duì)這種“多維度的變化”？如何利用面向?qū)ο蠹夹g(shù)來(lái)使得Tank類型可以輕松地沿著“平臺(tái)”和“型號(hào)”兩個(gè)方向變化，而不引入額外的復(fù)雜度？

?

意圖（Intent）

將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。

——《設(shè)計(jì)模式》GoF

橋模式不能只是認(rèn)為是抽象和實(shí)現(xiàn)的分離，它其實(shí)并不僅限于此。如下面的例子，兩個(gè)都是抽象的部分。更確切的理解，應(yīng)該是將一個(gè)事物中多個(gè)維度的變化分離。

?對(duì)于這種在多個(gè)維度上都會(huì)有變化或擴(kuò)充需求的項(xiàng)目來(lái)說(shuō)，可以考慮引入橋接模式?；蛟S你會(huì)說(shuō)，不管是什么場(chǎng)景，不管什么模式，都可以是抽象場(chǎng)景的一個(gè)子類，但是，如果這樣的話，4個(gè)場(chǎng)景和3種模式就會(huì)產(chǎn)生12個(gè)子類，而10個(gè)場(chǎng)景5種模式就會(huì)有50個(gè)子類。一味進(jìn)行繼承并不是什么好方法，橋接模式的思想是把繼承轉(zhuǎn)化為組合，把乘法(10*5=50)轉(zhuǎn)化為加法(10+5=15)。?

例說(shuō)Bridge應(yīng)用

版本一?

先寫各種不同的坦克型號(hào)類T50、T75等繼承自Tank，然后再讓各種平臺(tái)的坦克繼承自對(duì)應(yīng)型號(hào)的類，如PCT50，PCT75繼承自T50等。這樣設(shè)計(jì)可能會(huì)有很多重復(fù)的代碼，例PCT50和PCT75。

?

版本二

因?yàn)槠脚_(tái)和坦克型號(hào)都是變化，所以我們把平臺(tái)的變化作為屬性放到基抽象類中。

平臺(tái)實(shí)現(xiàn)類

下面是整個(gè)代碼的骨架

Tank的型號(hào)，和Tank的平臺(tái)都繼承自各自的抽象類，因此它們的變化都不會(huì)影響到對(duì)方。而它們之間的關(guān)聯(lián)，我們使用組合的方式，把平臺(tái)類放到Tank類中作為屬性。這再次體現(xiàn)了組合優(yōu)先于繼承的思想。多繼承的方法就是版本一的代碼，這種方式子類和父類的關(guān)系太緊，造成緊耦合。

這就是橋模式，把變化引出了基類Tank，使得Tank僅守與型號(hào)的變化。

?

應(yīng)用程序

在環(huán)境交互中使用的都是抽象類，并且把平臺(tái)實(shí)現(xiàn)隱藏，在應(yīng)用程序中new平臺(tái)的方式也可以根據(jù)情況用Singleton模式或者Abstract Factory模式等實(shí)現(xiàn)。

?

結(jié)構(gòu)（Structure）

其中imp的地方就是一個(gè)組合。Abstraction就是我們之前例子中的Tank，它的子類RefinedAbstraction就是T50等型號(hào)。Implementor是TankPlatformImplementation類，ConcreteImplementorA和ConcreteImplementorB分別是PCTankImplementation和MobileTankImplementation。

整個(gè)設(shè)計(jì)模式的關(guān)鍵就是組合的使用。

?

Bridge模式的幾個(gè)要點(diǎn)

Bridge模式使用“對(duì)象間的組合關(guān)系”解耦了抽象和實(shí)現(xiàn)之間固有的綁定關(guān)系，使得抽象（Tank的型號(hào)）和實(shí)現(xiàn)（不同的平臺(tái)）可以沿著格子的維度來(lái)變化。

所謂抽象和實(shí)現(xiàn)沿著各自維度的變化，即“子類化”它們（比如不同的Tank型號(hào)子類，和不同的平臺(tái)子類），得到各個(gè)子類之后，便可以任意組合它們，從而獲得不同平臺(tái)上的不同型號(hào)。

Bridge模式有時(shí)候類似于多繼承方案，但是多繼承方案往往違背單一職責(zé)原則（即一個(gè)類只有一個(gè)變化的原因），復(fù)用性比較差。Bridge模式是比多繼承方案更好的解決方法。

下面是針對(duì)上面的例子，多繼承接口的一種寫法：?

這樣PCT50既需要寫T50的實(shí)現(xiàn)，又要寫Platform的實(shí)現(xiàn)，它把型號(hào)和平臺(tái)的變化都引入了PCT50。這樣就把兩個(gè)本不該扭在一起的事務(wù)扭在了一起，這樣的設(shè)計(jì)更加糟糕，而且也違背了類的單一職責(zé)原則。

Bridge模式的應(yīng)用一般在“兩個(gè)非常強(qiáng)的變化維度”，有時(shí)候即使有兩個(gè)變化的維度，但是某個(gè)方向的變化維度并不劇烈——換言之兩個(gè)變化不會(huì)導(dǎo)致縱橫交錯(cuò)的結(jié)果，并不一定要使用Bridge模式。

?

橋模式并不同于適配器模式，適配器模式其實(shí)是一個(gè)事后諸葛亮，當(dāng)發(fā)現(xiàn)以前的東西不適用了才去做一個(gè)彌補(bǔ)的措施。橋模式相對(duì)來(lái)說(shuō)所做的改變比適配器模式早，它可以適用于有兩個(gè)甚至兩個(gè)以上維度的變化。

總結(jié)

以上是生活随笔為你收集整理的桥梁模式和适配器模式的区别的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。