C++ 設計模式：橋接模式深度解析——分離抽象與實現

模式定義

橋接模式：將抽象部分與實現部分分離，使它們都可以獨立變化。屬於結構型模式。

核心隱喻：蠟筆 vs 毛筆

• 蠟筆：型號（大/中/小）× 顏色（7種）= 21 支。型號與顏色強耦合，新增一種顏色需生產 3 支新蠟筆。
• 毛筆：3 支毛筆（型號）+ 7 盒顏料（實現）= 10 件物品。型號與顏色解耦，獨立變化。

橋接模式就是將系統中兩個維度的變化分離為兩條獨立繼承體系，通過聚合橋接。

結構角色

• Abstraction：抽象化角色，定義高層接口，聚合 Implementor。
• RefinedAbstraction：修正抽象化，擴展接口。
• Implementor：實現化接口，定義底層操作。
• ConcreteImplementor：具體實現。

經典場景：跨平台播放器

變化維度一：音頻格式（MP3、WAV、WMA）
變化維度二：操作系統播放接口（Linux、Windows、Unix）
若強耦合：需 3×3=9 個類。橋接後：3 個 Player 子類 + 3 個 OS 子類，組合靈活。

代碼實現

// 實現化接口：操作系統播放
class OperatingSystem {
public:
    virtual ~OperatingSystem() {}
    virtual void playAudio() = 0;
};
class LinuxOS : public OperatingSystem { void playAudio() override { cout << "Linux"; } };
class WindowsOS : public OperatingSystem { void playAudio() override { cout << "Windows"; } };
class UnixOS : public OperatingSystem { void playAudio() override { cout << "Unix"; } };

// 抽象化角色：播放器
class Player {
protected:
    OperatingSystem* os;
public:
    Player() : os(nullptr) {}
    void setOS(OperatingSystem* o) { os = o; }
    virtual ~Player() {}
    virtual void play() = 0;
};

// 修正抽象化：具體格式播放器
class MP3Player : public Player {
public:
    void play() override { cout << "Play MP3 on "; os->playAudio(); cout << endl; }
};
class WAVPlayer : public Player {
public:
    void play() override { cout << "Play WAV on "; os->playAudio(); cout << endl; }
};
class WMAPlayer : public Player {
public:
    void play() override { cout << "Play WMA on "; os->playAudio(); cout << endl; }
};

// 客戶端組合
int main() {
    Player* mp3 = new MP3Player();
    mp3->setOS(new LinuxOS()); mp3->play();
    mp3->setOS(new WindowsOS()); mp3->play();
    mp3->setOS(new UnixOS()); mp3->play();
    // 同理 WAV、WMA...
}

橋接 vs 策略模式

優缺點

• 優點：抽象與實現分離、符合開閉原則、減少子類數量、隱藏實現細節。
• 缺點：增加系統理解難度、適用場景較窄（需明確兩個獨立變化維度）。

適用場景

1. 類存在兩個獨立變化維度，且都需要擴展。
2. 不希望使用繼承，或繼承導致類爆炸。
3. 需要在運行時切換實現（如換數據庫驅動、換渲染引擎）。

總結

橋接模式的精髓是「組合優於繼承」：將抽象接口與具體實現解耦，構建兩條平行繼承體系，通過聚合橋接。關鍵識別：系統中是否存在兩個「各自獨立演化」的維度？若是，橋接是最佳選擇。