• 橋接模式的概念與實現
• 為什麼叫橋接模式
• 橋接模式的適用場景

繼承是面向物件的三大特性之一，但很多時候使用繼承的結果卻不盡如人意。除了人盡皆知的緊耦合問題外，有的時候還會導致子類的快速膨脹。

設想這樣一個場景：最初設計的時候有一個型別Product，但後來隨著新需求的出現，X原因導致了它的變化，X有兩種情況，則通過繼承需要建立兩個新的子類ProductX1,ProductX2，但後來有出現了Y因素也會導致Product的變化，如果Y有三種情況，則會出現ProductX1Y1,ProductX1Y2,ProductX1Y3...等，一共2*3=6個類。

使用這種繼承的方式，如果再出現新的變化因素，或者某個變化因素出現了新的情況，都會導致子類的快速膨脹，給維護帶來很大的挑戰。

造成這個問題的根本原因是型別在沿著多個維度變化。為了應對變化，一般會通過抽象的方法，找到其中比較穩定的部分，然後抽象其行為，令客戶程式依賴於抽象而不是具體實現。同樣的道理，當一個型別同時受到多個因素變化的影響時，也通過把每個因素抽象，讓型別依賴於一系列抽象因素的辦法儘量處理這個問題，這便是橋接模式解決問題的思路。

橋接模式的概念與實現

GOF對橋接模式的描述為：
Decouple an abstraction from its implementationso that the two can vary independently.
— Design Patterns : Elements of Reusable Object-Oriented Software

橋接模式的UML類圖為

示例程式碼：

public interface IImpl
{
    void OperationImpl();
}

public interface IAbstraction
{
    IImpl Implementor { get; set; }
    void Operation();
}
public class ConcreteImplementatorA : IImpl
{
    public void OperationImpl()
    {
        ...
    }
}

public class ConcreteImplementatorB : IImpl
{
    public void OperationImpl()
    {
        ...
    }
}

public class RefinedAbstration : IAbstraction
{
    public IImpl Implementor { get; set; }

    public void Operation()
    {
        Implementor.OperationImpl();
    }
}
 

這樣子看起來還是比較抽象，再舉個具體的例子汽車-道路，目前汽車有小汽車、巴士兩類，路有水泥路、石子路兩類，這樣“車在路上行駛”就會有四種情況，這個場景用橋接模式來描述的話可以是：
汽車類的抽象與實現：

public interface IVehicle
{
    string Drive();
}

public class Car : IVehicle
{
    public string Drive()
    {
        return "Car";
    }
}

public class Bus : IVehicle
{
    public string Drive()
    {
        return "Bus";
    }
}

通過橋接模式關聯道路與汽車：

public abstract class Road
{
    protected IVehicle vehicle;
    public Road(IVehicle vehicle)
    {
        this.vehicle = vehicle;
    }

    public abstract string DriveOnRoad();
}

public class UnpavedRoad : Road
{
    public UnpavedRoad(IVehicle vehicle) : base(vehicle) { }
    public override string DriveOnRoad()
    {
        return vehicle.Drive() + " is on Unpaved Road";
    }
}

public class CementRoad : Road
{
    public CementRoad(IVehicle vehicle) : base(vehicle) { }
    public override string DriveOnRoad()
    {
        return vehicle.Drive() + " is on Cement Road";
    }
}

呼叫：

IVehicle vehicle = new Car();
Road road = new CementRoad(vehicle);
Console.WriteLine(road.DriveOnRoad());
// Car is on Cement Road
Speed speed = new FastSpeed(road);
Console.WriteLine(speed.DriveWithSpeed());
// Car is on Cement Road,

在這裡Road依賴的是IVehivle抽象，具體的汽車實現在呼叫的時候決定。
對比直接繼承出四種類型的方式，這樣做的好處貌似並不明顯，還是需要四個類，而且更復雜，但如果汽車或者道路型別繼續增加，或者引入了別的變化因素，情況就不一樣了。

為什麼叫橋接模式

有個疑惑是關於橋接模式的名稱的，為什麼叫橋接模式呢？之前的工廠、介面卡等名稱都挺形象的，但橋接模式好像有點不同，這要從橋接模式解決問題的思路說起，橋接模式更多的是提示我們面向物件的設計分解方式，可以概括為三步：

• 第一步，把依賴具體變成依賴抽象。
• 第二步，如果物件同時沿著多個維度變化，那就順次展開抽象因素。
• 第三步，為每個抽象因素提供具體實現。

示意圖：

到了第三步，就可以大概看出橋接模式的形象化表示了，IX、IY和IZ構成連線部（被稱為支座），而每個具體類形成了一個個橋墩。
所以橋接模式，是以抽象之間的依賴為橋面、以具體實現為橋墩，建起了一座連線需求與實現的橋樑。

橋接模式的適用場景

• 如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯絡。
• 設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化角色的改變對客戶端是完全透明的。
• 一個構件有多於一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。
• 雖然在系統中使用繼承是沒有問題的，但是由於抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。

參考書籍：
王翔著 《設計模式——基於C#的工程化實現及擴充套件》