從重構視角深度解析 Bridge 設計模式

引言：為什麼需要 Bridge 模式？

在實際系統開發中，過度使用繼承導致類層次爆炸、維護困難是常見痛點。Java 單繼承限制更迫使開發者構建深層繼承鏈。Bridge 模式 正是為了解決「多維度變化」而生：將抽象部分（高層控制邏輯）與實現部分（具體操作細節）解耦，使二者可獨立演化。本文通過一個查詢系統的逐步重構，演示 Bridge 模式的自然誕生過程。

場景：多條件查詢系統的演進

初始版本：充滿 if-else 的單體類

需求：支持「查詢客戶信息」與「查詢帳戶信息」兩類業務，數據分別存儲於總部 Oracle 與分公司 Sybase 兩種數據庫。初級寫法在 SearchAction 中雙層 if-else 判斷業務類型與數據庫類型，直接拼 SQL、獲取連接、執行查詢。缺點顯而易見：

• 新增業務或數據庫需修改核心邏輯，違反開閉原則。
• 代碼重複嚴重（連接創建、結果集處理邏輯反復）。
• 單元測試極其困難。

第一步重構：提取「實現」維度——DAO + 簡單工廠

識別出「數據庫操作」為變化維度，定義接口 SearchDB：

public interface SearchDB {
    Vector searchFromDB(String sql);
}

提供 SearchDBOracleImpl、SearchDBSybaseImpl 兩種實現。引入 SearchFactory 根據 dbType 動態創建實例。Action 代碼簡化為：

SearchDB dao = SearchFactory.createSearch(dbType);
return dao.searchFromDB(sql);

成果：數據庫實現解耦，新增數據庫只需加實現類與工廠判斷，業務邏輯不變。體現「針對接口編程」與「組合優於繼承」。

第二步重構：提取「抽象」維度——模板方法模式

觀察發現：無論查詢客戶還是帳戶，流程固定為「構建 SQL → 執行查詢 → 返回結果」。將此流程上抽為抽象類 SearchAction：

public abstract class SearchAction {
    protected SearchDB dao;

    protected SearchDB createSearchImpl(int dbType) {
        return SearchFactory.createSearch(dbType);
    }

    protected abstract String buildSql(); // 子類實現具體 SQL

    public final Vector executeQuery(int dbType) { // 模板方法
        dao = createSearchImpl(dbType);
        return dao.searchFromDB(buildSql());
    }
}

具體業務類僅需實現 buildSql()：

public class SearchCustomerAction extends SearchAction {
    protected String buildSql() { return "SELECT * FROM Customer"; }
}

public class SearchAccountAction extends SearchAction {
    protected String buildSql() { return "SELECT * FROM Account"; }
}

再引入 ActionFactory 根據 actionType 創建具體 Action。最終調用端極其簡潔：

SearchAction action = ActionFactory.createAction(actionType);
return action.executeQuery(dbType);

Bridge 模式結構映射

核心優勢總結

1. 雙向獨立擴展：新增業務類型只擴展 Abstraction 子類；新增數據庫只擴展 Implementor 子類，互不影響。
2. 隱藏實現細節：客戶端無需知曉具體數據庫驅動、連接串、SQL 方言等細節。
3. 符合開閉原則：對擴展開放，對修改關閉。
4. 運行時動態綁定：可根據配置或用戶選擇動態組合抽象與實現（如同一業務切換數據源）。

適用場景判斷

• 類存在兩個或多個獨立變化維度（如：形狀/顏色、業務類型/持久化方式、界面風格/底層渲染引擎）。
• 不希望在繼承層次中硬編碼所有組合（避免類爆炸）。
• 需要在運行時根據條件切換實現方式。

避坑指南

Bridge 不等於「隨意拆分接口」。關鍵在於識別穩定的高層協議（抽象）與易變的底層實現（實現）。若系統僅有單一變化維度，或抽象與實現緊密綁定無獨立演化需求，直接繼承或策略模式可能更簡潔。