設計模式之（九）橋接模式（Bridge）

　　橋接模式是怎麼誕生的呢？來看一個場景。

　　一個軟件企業開發一套系統，要兼容全部的不一樣類型硬件和和各類操做系統。不一樣種類硬件主要是 電腦、平板電腦、手機。各類操做系統是蘋果系統、windows 系統、Linux 系統。設計人員給出了須要適配的類圖。

                                              

         這個設計根據列出來了須要建立的 7 個類。經過集成的方式來實現。這樣就實現了軟件如要適配的軟硬件的須要。可是有什麼問題呢。很顯然就是擴展起來筆記麻煩。例如：華爲的鴻蒙操做系統出來了，並且是手機、平板、電腦都能用的操做系統。這樣咱們就須要擴展 3 個類。這仍是簡單的業務狀況。要是複雜再複雜些的。那麼這樣的擴展就比較麻煩。那麼接下來咱們接觸的 橋接模式就可以很好的解決這個問題。先看下橋接模式的定義：

        將抽象部分與實現部分分離，使它們均可以獨立的變化。

        這種定義我老是弄不清除抽象部分和實現部分，都值得是什麼。可是後面的 均可以獨立的變化 看明白了。經過看其餘的一些文檔。實際就是在業務場景中有兩個及以上的維度變化時，把不一樣的維度都獨立成類，某個維度的類變化影響不到另一個維度的變化便可。而後在須要使用的試用使他們經過聚合的方式聯繫起來一塊兒工做。這種聚合猶如橋樑，所以這種解決問題設計方式就叫橋接模式。

        經過橋接模式的分析上面的業務場景。  首先來分析變化維度，很明顯操做系統是一個維度；各種硬件是一個維度。根據交接模式改造一下上面的結構：

         接下來用簡單的單位實現一下這個設計示意圖。

// 硬件抽象類 
public abstract class AbstractHardware {
    
    private SoftwareOS os;
    
    public AbstractHardware(SoftwareOS os){
        this.os = os;
    }
    
    public SoftwareOS getOs() {
        return os;
    }
    
    public abstract void runOS();
}

//電腦，繼承硬件抽象類
public class Computer extends AbstractHardware {

    public Computer(SoftwareOS os) {
        super(os);
        // TODO Auto-generated constructor stub
    }
    
    public void runOS(){
        String Str = this.getOs().funRun();
        System.out.println("電腦類兼容："+Str);
    }
    
}

//手機類，繼承硬件抽象類
public class Cellphone extends AbstractHardware{

    public Cellphone(SoftwareOS os) {
        super(os);
        // TODO Auto-generated constructor stub
    }

    @Override
    public void runOS() {
        // TODO Auto-generated method stub
        String str = this.getOs().funRun();
        System.out.println("手機兼容："+str);
    }
    
}

//平板電腦類，繼承硬件抽象類
public class boardCom extends AbstractHardware {
       ......
}

//操做系統接口
public interface SoftwareOS {
    
    public String funRun();
}

//蘋果操做系統，實現操做系統接口
public class Mac implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Mac 操做系統";
    }
}

//安卓操做系統，繼承操做系統接口
public class Andriod implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return " Andriod 操做系統";
    }

}

// Linux 類，實現操做系統接口
public class Linux implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Linux 操做系統";
    }
    
}

// Windows 類，實現操做系統接口
public class Windows implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Windows 操做系統";
    }
}

// 測試類
public class Client {
    public static void main(String[] args) {
        
        // 電腦類兼容配置
        AbstractHardware computer = new Computer(new Mac());
        computer.runOS();
        
        computer = new Computer(new Linux());
        computer.runOS();
        
        //手機類兼容配置
        AbstractHardware cphone = new Cellphone(new Andriod());
        cphone.runOS();
        
        cphone = new Cellphone(new Mac());
        cphone.runOS();
        
        // 平板電腦兼容配置 .....
        
    }
}

/**************************結果*****************************/

　　　　電腦類兼容：Mac 操做系統
　　　　電腦類兼容：Linux 操做系統
　　　　
　　　　手機兼容： Andriod 操做系統
　　　　手機兼容：Mac 操做系統
　　　　

　　隨着科技產業的不斷髮展，華爲開發出來全方位操做系統：鴻蒙，這時候就須要擴展操做系統這個維度的類。擴展以下：

//鴻蒙操做系統，實現操做系統接口
public class HongMeng implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "鴻蒙 操做系統";
    }

}

// 測試類
public class Client {
    public static void main(String[] args) {
        
        // 電腦類兼容配置
        AbstractHardware computer = new Computer(new HongMeng());
        computer.runOS();
        //手機類兼容配置
        AbstractHardwarecphone = new Cellphone(new HongMeng());
        cphone.runOS();
        
        // 平板電腦兼容配置 .....
    }
}

/**************************結果*****************************/

　　　　電腦類兼容：鴻蒙 操做系統
　　　　手機兼容：鴻蒙 操做系統

 

 分析橋接模式

　　經過上面的例子，咱們看出來，橋接模式經過把業務場景中不一樣的兩個維度獨立了出來，在試用的時候根據須要類配合試用，調用的時候更加靈活。並且須要擴展時，只須要擴展有變化的維度便可。

　　若是不用橋接模式，那麼就須要 電腦、平板電腦、手機都擴展鴻蒙操做系統的類，若是是實際運用中場景更復雜，擴展的工做量就更大。

　　另外也體現了開閉原則。由於擴展時候頂層的抽樣類和接口是不變化的，兩個維護的關聯也是不變的，只須要根據擴展添加新類便可。

       經過這個設計模式的代碼實現方式，咱們也總結一下：繼承的耦合性更強，而組合或者說是聚合的靈活性更高。

　　那麼這個模式的本質是什麼呢：就是分析業務場景變化維度。而後讓不一樣的維度相互獨立，一個維度變化另一個維度不用跟着修改，使得代碼更容易擴展。