設計模式之橋接模式

設計模式之橋接模式

特點

　　將抽象部分與實現部分分離，使他們都可以獨立地進行變化。爲了達到讓抽象部分和實現部分獨立變化的目的，抽象部分會擁有實現部分的接口對象，有了實現部分的接口對象之後，就能夠通過這個接口來調用具體實現部分的功能。橋接在程序上就體現成了抽象部分擁有實現部分的接口對象，維護橋接就是維護這個關係，也就是說，橋接模式中的橋接是一個單方向的關係，只能夠抽象部分去使用實現部分的對象，而不能反過來。
　　橋接模式適用於以下的情形：

如果一個系統需要在構建的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承聯繫，可以通過橋接模式使他們在抽象層建立一個關聯關係；
那些不希望使用繼承或因爲多層次繼承導致系統類的個數極具增加的系統；
一個類存在兩個獨立變化的維度，而這兩個維度都需要進行擴展。

橋接模式也分爲四個角色：

Abstraction：抽象部分
該類保持一個對實現部分對象的引用，抽象部分中的方法需要調用實現部分的對象來實現，該類一般爲抽象類；
RefinedAbstraction：優化的抽象部分
抽象部分的具體實現，該類一般對抽象部分的方法進行完善和擴展；
Implementor：實現部分
可以爲接口或者是抽象類，其方法不一定要與抽象部分中的一致，一般情況下是由實現部分提供基本的操作，而抽象部分定義的則是基於實現部分基本操作的業務方法；
ConcreteImplementorA 和 ConcreteImplementorB ：實現部分的具體實現
完善實現部分中定義的具體邏輯。

一個具體的例子：

abstract class AbstractRoad{  
    AbstractCar aCar;  
    void run(){};  
}  
abstract class AbstractCar{  
    void run(){};  
}  

class Street extends AbstractRoad{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        aCar.run();  
        System.out.println("在市區街道行駛");  
    }  
}  
class SpeedWay extends AbstractRoad{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        aCar.run();  
        System.out.println("在高速公路行駛");  
    }  
}  
class Car extends AbstractCar{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("小汽車");  
    }  
}  
class Bus extends AbstractCar{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("公交車");  
    }  
}  

public static void main(String[] args){  

    AbstractRoad speedWay = new SpeedWay();  
    speedWay.aCar = new Car();  
    speedWay.run();  

    AbstractRoad street = new Street();  
    street.aCar = new Bus();  
    street.run();  
}  

效果及實現要點：
1．Bridge模式使用“對象間的組合關係”解耦了抽象和實現之間固有的綁定關係，使得抽象和實現可以沿着各自的維度來變化。
2．所謂抽象和實現沿着各自維度的變化，即“子類化”它們，得到各個子類之後，便可以任意它們，從而獲得不同路上的不同汽車。
3．Bridge模式有時候類似於多繼承方案，但是多繼承方案往往違背了類的單一職責原則（即一個類只有一個變化的原因），複用性比較差。Bridge模式是比多繼承方案更好的解決方法。
4．Bridge模式的應用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度，但是某個方向的變化維度並不劇烈——換言之兩個變化不會導致縱橫交錯的結果，並不一定要使用Bridge模式。

適用性：
在以下的情況下應當使用橋樑模式：
1．如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯繫。
2．設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化角色的改變對客戶端是完全透明的。
3．一個構件有多於一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。
4．雖然在系統中使用繼承是沒有問題的，但是由於抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。
總結：
Bridge模式是一個非常有用的模式，也非常複雜，它很好的符合了開放-封閉原則和優先使用對象，而不是繼承這兩個面向對象原則。