23種設計模式之橋接模式

一、定義

將抽象部分和實現部分分離，使它們均可以獨立的變化。又稱爲柄體（Handle and Body）模式或者接口（Interface）模式。

二、模式結構

橋接模式由四部分組成：

• 抽象化（Abstraction）角色：抽象化給出的定義，並保存一個對實現化對象的引用。
• 修正抽象化（RefinedAbstraction）角色：擴展抽象化角色，改變和修正父類對抽象化的定義。
• 實現化（Implementor）角色：這個角色給出實現化角色的接口，但不給出具體的實現。必須指出的是，這個接口不必定和抽象化角色的接口定義相同，實際上，這兩個接口能夠很是不同。實現化角色應當只給出底層操做，而抽象化角色應當只給出基於底層操做的更高一層的操做。
• 具體實現化（ConcreteImplementor）角色：這個角色給出實現化角色接口的具體實現。

三、實例

3.1 形狀類（抽象化角色）

public abstract class Shape {
    protected Color color;
    
    public Shape(Color color) {
        this.color = color;
    }
    
    public abstract void draw();
}
複製代碼

3.2 修正抽象類角色

public class Circle extends Shape {
    
    public Circle(Color color) {
        super(color);
    }
    
    @Override
    public void draw() {
        color.bepaint("圓形");
    }
}
複製代碼

public class Rectangle extends Shape {

    public Rectangle(Color color) {
        super(color);
    }
    
    @Override
    public void draw() {
        color.bepaint("長方形");
    }
}
複製代碼

public class Square extends Shape {

    public Square(Color color) {
        super(color);
    }
    
    @Override
    public void draw() {
        color.bepaint("正方形");
    }
}
複製代碼

3.3 顏色接口（抽象化角色）

public interface Color {
    public void bepaint(String shape);
}
複製代碼

3.4 具體實現化角色

public class White implements Color {
    
    @Override
    public void bepaint(String shape) {
        System.out.println("白色的" + shape);
    }
}
複製代碼

public class Black implements Color {
    
    @Override
    public void bepaint(String shape) {
        System.out.println("黑色的" + shape);
    }
}
複製代碼

3.5 客戶端調用

public class Client {
    
    public static void main(String[] args) {
        Shape circle = new Circle(new White());
        circle.draw();
        
        Shape square = new Square(new Black());
        square.draw();
    }
}
複製代碼

四、適用場景

• 若是一個系統須要在構件的抽象化角色和具體化角色之間增長更多的靈活性，避免在兩個層次之間創建靜態的繼承聯繫，經過橋接模式可使它們在抽象層創建一個關聯關係。
• 抽象化角色和實現化角色能夠以繼承的方式獨立擴展而互不影響，在程序運行時能夠動態將一個抽象化子類的對象和一個實現化子類的對象進行組合，即系統須要對抽象化角色和實現化角色進行動態耦合。
• 一個類存在兩個獨立變化的維度，且這兩個維度都須要進行擴展。
• 雖然在系統中繼承是沒有問題的，可是因爲抽象化角色和具體化角色須要獨立變化，設計要求須要獨立管理這二者。
• 對於那些不但願使用繼承或由於多層次繼承致使類的個數急劇增長的系統，橋接模式尤其適用。

五、在JDBC的源碼分析

六、優缺點

6.1 優勢

• 分離抽象接口及其實現部分。橋接模式使用「對象間的關聯關係」解耦了抽象和實現之間固有的綁定關係，使得抽象和實現能夠沿着各自的維度來變化。所謂抽象和實現沿着各自維度的變化，也就是說抽象和實現再也不同一個繼承層次結構中，而是「子類化」它們，使它們各自都具備本身的子類，以便任何組合子類，從而得到多維度組合對象。
• 在不少狀況下，橋接模式能夠取代多層繼承方案，多層繼承方案違背看「單一職責原則」，複用性較差，且類的個數很是多，橋接模式是比多層繼承方案更好的解決方法，它極大減小了子類的個數。
• 橋接模式提升了系統的可擴展性，在兩個變化維度中任意擴展一個維度，都不須要修改原有系統，符合「開閉原則」。

6.2 缺點

• 橋接模式的使用會增長系統的理解與設計維度，因爲關聯關係創建在抽象層，要求開發者一開始就針對抽象層進行設計與編程。
• 橋接模式要求正確識別出系統中兩個獨立變化的維度，所以其使用範圍具備必定的侷限性，如何正確識別兩個獨立維度也須要必定的經驗積累。

特別聲明：一、如若文中有錯之處，歡迎大神指出。 二、文章是參考網上一些大神的文章，本身整理出來的，如如有侵權，可聯繫我刪除。