在複雜系統的開發中，我們常常需要面對多個維度的變化。橋模式（Bridge Pattern）是一種結構型設計模式，它的主要目的是將抽象部分與實作部分分離，以便它們可以獨立變化。透過橋接模式，開發者能夠在不同維度的功能上實現解耦，使系統更具靈活性和可擴展性。本文將詳細介紹橋接模式的概念、與其他相似模式的差異、解決的問題、Golang中的實作範例，以及實際應用中的注意事項。

什麼是橋模式（Bridge Pattern）？

橋模式（Bridge Pattern）將抽象與實現分離，使它們可以獨立變化。換句話說，橋模式為兩個獨立的變化維度建立橋樑。這樣即使一個維度發生變化，也不會影響到另一個維度，進而減少程式碼的耦合性。

橋模式的組成部分

• 抽象部分（Abstraction）：定義了客戶端要使用的高層介面。
• 具體抽象（Refined Abstraction）：實作了抽象部分的接口，並且可以呼叫實作部分的邏輯。
• 實作部分（Implementor）：定義實作抽象部分所需的底層介面。
• 具體實作（Concrete Implementor）：提供實現部分的具體邏輯。

透過橋模式，抽象和實現都可以獨立演化，彼此不受影響。抽象部分負責定義業務邏輯，而實現部分負責具體的操作實現。

橋模式與其他相似模式的區別

橋接模式與一些常見的結構型設計模式，如適配器模式、組合模式和裝飾模式，存在一些相似之處，但它們的目的和使用場景有所不同。

1. 適配器模式（Adapter Pattern）：

   • 目標：適配器模式將一個類別的介面轉換為客戶端所期望的接口，以解決接口不相容問題。
   • 差別：適配器模式是事後設計，用於將現有的類別適配到新介面；而橋接模式是預先設計，用於解耦抽象和實作。
     適配器模式具體可查看博文：適配器模式

2. 組合模式（Composite Pattern）：

   • 目標：組合模式用於將物件組合成樹狀結構，以表示「部分-整體」關係。
   • 差別：組合模式主要關注物件的層次關係，而橋接模式關注抽象和實現的分離。
     組合器模式具體可查看博文：組合模式

3. 裝飾模式（Decorator Pattern）：

   • 目標：裝飾模式透過動態地為物件添加新功能來擴展物件的行為。
   • 差別：裝飾模式強調功能的動態增強，而橋接模式強調結構的解耦與彈性。
     裝飾器模式具體可查看博文：裝飾模式

橋模式解決了什麼問題？

橋模式主要解決了以下問題：

1. 多維度變化：當一個系統需要在多個維度上變更時（如多個平台和多種業務需求），橋模式能夠將這些維度解耦，使得各個維度可以獨立變更。
2. 減少類別的數量：透過橋接模式，不需要為每個特定實作創建大量的子類，從而避免類爆炸。
3. 增強系統的可擴展性：橋模式使得新增抽像或實作部分時無需修改現有程式碼，進而提升系統的可擴充性。

Golang中的橋模式實現

下面透過一個範例，展示如何在Golang中實現橋模式。假設我們需要開發一個訊息發送系統，支援不同的訊息類型（如普通訊息和緊急訊息），並且支援不同的發送方式（如簡訊和郵件）。橋接模式可以幫助我們在訊息類型和發送方式這兩個維度上實現解耦。

範例：訊息發送系統

1. 定義實現部分的介面

package main 

import "fmt" 

// MessageSender 介面：定義訊息傳送方式
type MessageSender interface { 
	Send(message string) 
}

2. 實現具體的發送方式

// SMS 結構體：透過簡訊傳送訊息
type SMS struct{} 

func (s *SMS) Send(message string) { 
	fmt.Printf("Sending SMS: %s\n", message) 
} 

// Email 結構體：透過郵件傳送訊息
type Email struct{} 

func (e *Email) Send(message string) { 
	fmt.Printf("Sending Email: %s\n", message) 
}

3. 定義抽象部分的接口

// Message 介面：定義訊息類型
type Message interface { 
	SendMessage(content string) 
}

4. 實現具體的訊息類型

// CommonMessage 結構體：普通訊息
type CommonMessage struct {
	sender MessageSender
}

func (c *CommonMessage) SendMessage(content string) {
	c.sender.Send("[Common] " + content)
}

// UrgentMessage 結構體：緊急訊息
type UrgentMessage struct {
	sender MessageSender
}

func (u *UrgentMessage) SendMessage(content string) {
	u.sender.Send("[Urgent] " + content)
}

5. 使用橋模式的範例程式碼

func main() {
	// 建立特定的傳送方式
	sms := &SMS{}
	email := &Email{}

	// 建立不同類型的訊息，並指定傳送方式
	commonMessage := &CommonMessage{sender: sms}
	urgentMessage := &UrgentMessage{sender: email}

	// 傳送訊息
	commonMessage.SendMessage("Hello, this is a normal message.")
	urgentMessage.SendMessage("This is an urgent message!")
}

輸出

Sending SMS: [Common] Hello, this is a normal message. Sending Email: [Urgent] This is an urgent message!

程式碼解析

1. MessageSender 介面：定義了訊息發送方式的接口，不同的發送方式（如簡訊和郵件）都實現了該接口。
2. CommonMessage 和UrgentMessage 結構體：代表不同類型的消息，它們透過組合 MessageSender 接口實作不同的發送方式。
3. 橋模式的解耦：訊息類型和發送方式是兩個獨立的維度，透過橋接模式實現了解耦，使它們可以獨立變化。

實際開發中的應用

橋模式在實際開發中有廣泛的應用場景，尤其是在需要支援多個維度變化的系統中。以下是幾個典型的應用場景：

1. 跨平台應用：在開發跨平台應用時，可以使用橋接模式將平台相關的實作與業務邏輯解耦。例如，UI庫可以在不同平台上實現不同的渲染邏輯，而業務邏輯可以保持不變。

2. 資料庫操作：橋接模式可以將資料庫的操作介面與特定資料庫的實作解耦。例如，業務邏輯可以透過一個通用介面存取不同的資料庫（如MySQL、PostgreSQL），而不需要了解特定的實作細節。

3. 網路傳輸：實現網路傳輸系統時，可以使用橋接模式將資料的傳輸協定（如HTTP、WebSocket）與業務邏輯分離，使得系統更有彈性。

使用橋模式的注意事項

1. 設計複雜度增加：橋模式雖然提高了系統的靈活性，但也增加了設計的複雜性。在系統不需要多個維度獨立變更時，不必使用橋接模式。
2. 適用場景明確：橋模式適用於多個維度獨立變化的場景。如果系統只有一個維度的變化，直接使用繼承或組合可能會更簡單。
3. 抽象介面的設計：橋接模式依賴介面的設計，因此需要確保介面的設計夠通用，能夠滿足多種實作方式的需求。

橋模式與繼承的對比

總結

橋接模式是一種非常有用的設計模式，透過將抽象部分與實作部分分離，提升了系統的靈活性和可擴展性。在Golang中，橋模式的實作相對簡單，透過介面和結構體組合即可實現。橋接模式特別適合用於處理多維度變化的系統，如跨平台應用、資料庫操作和網路傳輸等場景。

參考連結

• 設計模式- 橋接模式
• Go 設計模式