筆記：Design Pattern for Bridge Pattern

如果在系統裡，有二個維度（或更多）是屬於正相關的關係，並且耦合度又強的時候，當結構設計不良時，應該就很有機會讓你的系統類別快速的增長或是程式裡的控制流程變得更加噁心。

情境

舉一個 Brdige Pattern 常用的例子。假設有一套「遙控器與電視」的系統，在不使用像 Brdige Pattern 的結構時，每個品牌的遙控器都要對應各個不同品牌的電視，這時候就會有一堆底下的狀況：

• SonyRemoteToSonyTV
• SonyRemoteToSamsungTV
• LgRemoteToSonyTV
• ……。

或著是更慘，你的程式裡全部都是用流程控制來切開。例：if-else or switch-case。

那每當要新增一個「搖控器」（第一個維度）或「電視品牌」（第二個維度）時，相關聯的另一個維度預期都會有 N 個類別或程式區塊要被異動到。

又或著像實作資料存取層時。假設有 UserRepo & OrderRepo 負責 CRUD 資料，且需要支援 Oracle or MongoDb（或以後要新增其他的）。

在沒有實作 Bridge Pattern 的情況下，很可能會有 OracleUserRepo, MongoUserRepo or OracleOrderRepo 的類別出現。

如果未來又要多加 Redis 時，可能又要再多出 RedisUserRepo。

Bridge pattern UML

Solution

把其中一個維度往上抽一層當作介面，並且拿來當另一個維度的成員變數。

以資料存取層為例：

1.建立一個 IDao 介面，裡面有基本的 Create,Update or Delete 等方法。

2.然後看是要透過注入或 factory 的方式來拿到相關的 IDao 實作。

3.在UserRepo or OrderRepo 裡面的程式流程只管呼叫 _dao.Create() 等相關的方法，就不再去管底層是 Oracle or MongoDb 的實作。

個人經驗

在 Bridge Pattern 的原始 UML 定義中，通常會用一個抽象類別先把第一個維度往上抽一層，然後實作的類別裡再用一個變數來使用第二個維度的 Interface。

只是以我個人的使用，這個第一個維度再抽一層抽象類別就有點看個人。

以資料庫存取 Repo 的例子來說，UserRepo & OrderRepo 我是不會再往上抽了。

因為在把這個所謂的第一個維度 or 第二個維度 往上抽的動作，其實要有點小心。

如果你抽的不是較通用的功能或方法時，很可能這個往上抽的動作意義是並不大的，甚至有點多餘。

例如資料庫存取的例子，如果 IDao 往上抽的叫做 CreateUser or UpdateUser，那這種方法就不適合；但如果是叫 Create or Updaet 的方法時，它較相對較為合適。（或著是搖控器的例子，搖控器統一都會有 靜音 or 轉台 的功能）

核心的概念要回到一個重點，不要有鎚子後就把所有東西都當釘子了。不然就是所謂的過度設計了。

參考資料
Design Patterns: Bridge Pattern
軟體就該是軟的：設計模式思維實踐