設計模式(7) 橋接模式-有解無憂

橋接模式的概念與實作
為什么叫橋接模式
橋接模式的適用場景

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

設想這樣一個場景：最初設計的時候有一個型別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類圖為
橋接模式 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#的工程化實作及擴展》

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/4551.html

標籤：設計模式

上一篇：【設計模式】前言

下一篇：原型模式