C# 設計模式實戰：橋接模式解耦抽象與實作

編輯：關於C語言

橋接模式將抽象部分與其實作部分分離，使它們都可以獨立變化。本文透過一個「聊天室管理員踢人」的生動場景，展示如何用 C# 實作橋接模式，避免繼承爆炸，實現管理員行為與聊天室核心邏輯的正交復用。

場景痛點：繼承的組合爆炸

假設聊天室有多種踢人策略：

女管理員：禮貌勸離 "Please Go Out!"
男管理員：粗暴踢出 "Out! Shit!"

若用繼承：ChatRoom → FemaleChatRoom/MaleChatRoom，未來新增「機器人管理員」、「VIP管理員」……類別數量呈指數增長。橋接模式將「管理員行為」抽離為獨立介面，聊天室透過組合引用，實現雙向獨立擴展。

核心代碼實作

1. 實作介面：管理員行為契約

public abstract class Manager
{
    public abstract void KickOut();
}

2. 具體實作：不同風格的管理員


public class FemaleManager : Manager
{
    public override void KickOut() => Console.WriteLine("Please Go Out!");
}

public class MaleManager : Manager
{
    public override void KickOut() => Console.WriteLine("Out! Shit!");
}

3. 抽象類別：聊天室核心邏輯


public class ChatRoom
{
    private Manager _manager;

    public Manager ChatRoomManager
    {
        set => _manager = value;
    }

    public void KickOut()
    {
        _manager?.KickOut(); // 委派給具體實作
    }
}

4. 客戶端測試：運行時動態切換策略


class Program
{
    static void Main()
    {
        var room = new ChatRoom();

        room.ChatRoomManager = new FemaleManager();
        room.KickOut(); // Please Go Out!

        room.ChatRoomManager = new MaleManager();
        room.KickOut(); // Out! Shit!

        Console.ReadKey();
    }
}

UML 結構速覽

<> Manager
     ▲
     | implements
┌────┴────┐
FemaleManager  MaleManager

ChatRoom ◄────── Manager (組合/橋接)
  │
  └── KickOut() → 委派 _manager.KickOut()

橋接模式 vs. 策略模式：一針見血的區別

維度	橋接模式	策略模式
意圖	結構性分離：抽象與實作獨立演化	行為性封裝：算法族群可互換
關係	抽象持有實作介面（組合）	Context 持有 Strategy 介面（組合）
變化軸	兩個維度：抽象層次 × 實作細節	單一維度：算法實現
典型場景	跨平台 GUI、驅動程式、訊息推送渠道	排序算法、支付方式、壓縮策略

本例中 ChatRoom 為抽象，Manager 為實作，兩者各自擴展互不影響 —— 這正是橋接模式的核心價值。

進階應用：多維度橋接

若聊天室還有「訊息過濾」、「日誌記錄」等維度，可引入多個橋接介面：


public class ChatRoom
{
    public IManager Manager { get; set; }
    public IFilter Filter { get; set; }
    public ILogger Logger { get; set; }
    // ...
}

每個維度獨立實作、獨立注入，完美符合單一職責原則與開放封閉原則。