橋接模式曹阔，屬于結構型模式半开。
意圖：將抽象部分與它的實現(xiàn)部分分離，使他們都可以獨立的變化赃份。
這句話其實有點難理解稿茉， 在軟件工程里面，哪些部分是抽象，哪些部分是實現(xiàn)呢漓库？其實這里沒有一個具體的定義。下面幾句摘自其他書籍园蝠，便于我們理解：
1：《大話設計模式》：實現(xiàn)系統(tǒng)可能有多角度分類渺蒿，每一種分類都有可能變化，那么就把多種角度分離出來讓他們獨立變化彪薛，減少他們之間的耦合茂装。
2：《設計模式java版》：橋接模式是一種很實用的結構型設計模式，如果軟件系統(tǒng)中某個類存在兩個獨立變化的維度善延，通過該模式可以將這兩個維度分離出來少态，使兩者可以獨立擴展，讓系統(tǒng)更加符合“單一職責原則”易遣。與多層繼承方案不同彼妻，它將兩個獨立變化的維度設計為兩個獨立的繼承等級結構，并且在抽象層建立一個抽象關聯(lián)豆茫，該關聯(lián)關系類似一條連接兩個獨立繼承結構的橋侨歉，故名橋接模式。
在這里我們其實沒有絕對的定義抽象部分和顯示部分揩魂，我們只知道把兩個獨立的維度分離出來幽邓，并且不影響他們各自的變化的結構就是橋接模式的結構。
UML圖：
今天還是以《完美國際》游戲為例火脉，來做這個demo（誰讓我那么喜歡這款游戲）
問題：
在游戲中牵舵，我們有很多職業(yè)，比如武俠倦挂，妖獸畸颅，羽芒等等，這些職業(yè)也都可以拿上武器妒峦，斧頭重斑，長槍，刀等等肯骇；其實在這里窥浪，我們已經(jīng)有了兩個維度，職業(yè)和武器笛丙。那么怎么才能讓每個職業(yè)都可以拿上自己的武器漾脂，或者反過來說，這些武器胚鸯，每個職業(yè)都可以使用呢骨稿？
方案1：
有人會說，這還不簡單，我們可以設計很多職業(yè)坦冠，比如形耗，刀武俠，刀妖獸辙浑，刀羽芒激涤，斧頭武俠，斧頭妖獸判呕，斧頭羽芒等等倦踢。如圖：
方案1缺陷：首先這樣設計是沒問題的，但是前面已經(jīng)說過侠草，職業(yè)和武器本身就是兩個不同維度的東西辱挥，現(xiàn)在非要整合在了一起，代碼耦合性太高不說边涕，更是違背了設計模式的單一職責原則晤碘，接口隔離原則，開閉原則奥吩。
方案2：
使用橋接模式哼蛆，把職業(yè)和武器兩維度橋接在一起，但是每個維度又可以獨立發(fā)展霞赫，如圖：
圖中腮介，職業(yè)和武器是兩個獨立的維度，他們互不影響端衰，主要是由職業(yè)抽象類進行的兩個維度的橋接叠洗，代碼如下：
武器緯度（武器接口和具體實現(xiàn)）：
職業(yè)緯度:
測試類：
方案二總結：圖中可以看到，武器和職業(yè)兩個緯度旅东，互不影響灭抑，不論以后開通多少武器和職業(yè)，兩個類互不影響抵代，各自發(fā)展腾节。完全符合單一職責原則。圖中在職業(yè)抽象類中引入了武器的接口引用進行橋接荤牍，面向了接口案腺，降低了耦合。
總結：
1康吵、橋接模式實現(xiàn)了抽象化與實現(xiàn)化的脫耦劈榨。他們兩個互相獨立，不會影響到對方晦嵌。?
?2同辣、對于兩個獨立變化的維度拷姿，使用橋接模式再適合不過了。
?3旱函、對于“具體的抽象類”（我們將抽象類的屬性都讓實現(xiàn)類接口去做啦）所做的改變响巢，是不會影響到客戶。
