設計模式 之橋接模式

以前說過的翻譯計劃食言了。如今開始翻，從 結構型設計模式 橋接模式開始，由於以前的都在github上寫過了（稍後記得整理下）。

如今主流的設計模式主要分三大類

建立型設計模式，結構型設計模式，行爲型設計模式。

建立型設計模式：

工廠方法模式 抽象工廠模式 原型鏈模式 單例模式 建造者模式 對象池模式

結構型設計模式：

適配器模式 橋接模式  複合模式 裝飾模式 外觀模式 享元模式 私有類數據模式 代理模式

行爲型設計模式：

責任鏈模式 命令模式 解釋器模式 策略模式 訪問者模式 迭代模式 觀察者模式 備忘錄模式 模板方法模式 空對象模式 中介者模式 狀態模式

橋接模式

目的

• 解耦抽象類的實現，使二者獨立出來。

• 在層裏添加一個接口,銷燬對本身的子層的實現。

• 封裝的背後，是爲了更好的隔離。

問題

    "增強軟件的主線"已經經過使用一個抽象基類的子類提供不一樣的實現。編譯綁按期間它會在接口和實現之間加鎖。使抽象類和接口不能單獨擴展或組合。

動機
想象一下線程調度器

假設如今有兩種線程調度器，兩種操做系統或平臺。咱們該如何給它分類呢，咱們必須得給這兩種類型下的每種可能都新增一個類。若是咱們新增了一個平臺（好比說java的虛擬機），那麼如今咱們的系統看起來怎麼樣呢？

假設咱們有三種線程調度器，四種平臺，會怎樣？再假設咱們有五種線程調度器，十種平臺，又會怎樣？咱們要定義的對象數量是由調度器的數量和平臺的數量決定的。

橋接模式旨在重構兩個垂直層之間指數級增加的子類-----一個是爲了平臺獨立的抽象，一個是爲了平臺依賴的實現。

 

討論
分解組件的接口和實現爲兩個垂直的類層。接口類包含了一個pointer對抽象實現的類。這個pointer初始化爲 一個具體實現類的實例化, 可是後面全部的交互從接口類到實現類都被限制在包含在實現基類裏的抽象類裏。客戶端和接口類交互, 它把全部"表明"的請求轉化爲實現類。

接口對象是一個被客戶端使用的把手; 當實現對象或者"主體"，被安全地封裝以確保它可能被繼續使用，或被替換(又或在運行期間被分享出去)。
以下爲可能使用橋接模式的條件：
    你想動態綁定實現類
    由於接口過多和大量的實現致使類的數量劇增
    想在多個對象中分享一個實現
    想構建垂直不相關的類層
這樣作的好處:
    解耦了類的接口
    提高可擴展性
    對客戶端隱藏實現細節(能夠各自擴展子類的抽象類和接口類)

橋接是"把手/主體"的近義詞。這種設計模式在接口類的內部封裝了實現類。前者是主體,後者是把手。把手是用戶能看到的類，可是在主體內部運行。"橋接模式吧一個複雜的抽象類分解的更小，更容易管理。名字也反映了多個能夠操做它的類分享了單一資源（這翻的有點拗口）"

未完待續