設計模式（Design Patterns）是軟體工程中的一種經驗總結，它為常見的軟體設計問題提供了解決方案。雖然設計模式本身並不是具體的程式碼，而是一些可以重複使用的設計想法和原則，它們能夠幫助開發者寫出更靈活、可維護性強且可擴展的程式碼。

本篇部落格將詳細介紹設計模式的定義、意義、分類以及每類設計模式中的常見例子。透過深入了解這些內容，讀者可以對如何在專案中應用設計模式有更清晰的認識，並在遇到實際問題時能夠迅速找到合適的解決方案。

1. 什麼是設計模式？

設計模式是在物件導向程式設計中，經常出現的設計結構和最佳實踐。它是一種可重複使用的解決方案，用於應對在軟體設計中反覆出現的特定問題。簡單來說，設計模式並不是具體的程式碼，而是一種思考方式，指導開發者如何組織程式碼，以便程式碼更具擴展性、復用性和維護性。

設計模式起源於建築領域，由建築師克里斯托弗·亞歷山大（Christopher Alexander）首次提出，他將設計模式定義為：「描述在某個上下文中反覆出現的問題及其解決方案」。在軟體工程中，設計模式透過多年的開發經驗積累，幫助程式設計師避免常見錯誤並提高開發效率。

2. 為什麼要使用設計模式？

在軟體開發中，面對複雜的需求時，我們常常需要創造大量相互關聯的類別和物件。如果這些類別之間的關係被寫得過於緊密耦合，修改其中一個類別時可能會影響整個系統的運作。此外，系統的可擴展性和可維護性也會受到很大限制。設計模式透過提供標準化的設計方法，幫助開發者解決這些問題。

設計模式的優點包括：

• 提高程式碼可重複使用性：模式提供了一些通用的解決方案，可以在多個專案中重複使用。
• 提升程式碼的靈活性和可擴展性：透過解耦和抽象，設計模式使得程式碼更容易擴展和維護。
• 促進團隊溝通：設計模式提供了一種通用的語言，開發人員可以透過設計模式的名稱清晰地表達設計意圖。
• 簡化複雜問題的解決：設計模式提供了簡潔明了的解決方案，避免了複雜設計所導致的程式碼混亂。

3. 設計模式的分類

設計模式通常分為三大類：創建型模式、結構型模式和行為型模式。每個分類下有若干種設計模式，針對不同的設計需求。

3.1 創建型模式

創建型模式涉及物件的創建過程。它們為創建物件提供了一種方法，使系統更具靈活性和可擴展性。這些模式能夠將物件建立的過程與系統的其他部分解耦，從而避免由於直接實例化物件所帶來的依賴問題。

常見的創建型模式包括：

1. 單例模式（Singleton）：確保一個類別只有一個實例，並提供全域存取點。
2. 工廠方法模式（Factory Method）：定義一個接口，用於創建對象，但將實際創建對象的工作推遲到子類中。
3. 抽象工廠模式（Abstract Factory）：提供一個接口，用於創建相關或依賴對象的家族，而不需要指定具體類別。
4. 建造者模式（Builder）：將一個複雜物件的建構過程與它的表示分離，使得同樣的建構過程可以創造不同的表示。
5. 原型模式（Prototype）：透過複製現有物件來建立新的對象，而不是透過實例化新的類別。

單例模式（Singleton）

單例模式的目標是確保一個類別只有一個實例，並提供一個全域的存取點。這個模式適用於系統中只需要一個實例的場景，例如日誌記錄器、設定管理員或執行緒池等。

package main import ( "fmt" "sync" ) // Singleton是單例模式的實作type Singleton struct{} var instance *Singleton var once sync.Once // GetInstance確保只建立一個實例func GetInstance() *Singleton { once // GetInstance確保只建立一個實例func GetInstance() *Singleton { once .Do(func() { instance = &Singleton{} }) return instance } func main() { s1 := GetInstance() s2 := GetInstance() if s1 == s2 { fmt.Println("s1 和s2 是同一個實例") } }

工廠方法模式（Factory Method）

工廠方法模式允許子類決定實例化哪個類，並透過將物件建立邏輯放在子類中，來實現物件創建的靈活性。工廠方法模式特別適用於當物件建立過程比較複雜或經常變更時。

package main import "fmt" // Product 定義產品介面type Product interface { Use() } // ConcreteProduct 是Product介面的具體實作type ConcreteProduct struct{} func (p *ConcreteProduct) Use() { fmt.Println("使用具體產品") } // Factory 定義工廠介面type Factory interface { CreateProduct() Product } // ConcreteFactory 是特定工廠實作type ConcreteFactory struct{} func (f *ConcreteFactory) CreateProduct() Product { return &ConcreteProduct*ConcreteFactory) CreateProduct() Product { return &ConcreteProduct{} } func () { factory := &ConcreteFactory{} product := factory.CreateProduct() product.Use() }

3.2 結構型模式

結構型模式關注物件和類別的組合。這些模式透過使不同類別之間的介面更加一致，簡化了物件的交互過程。結構型模式通常透過使用繼承或介面機制，將類別或物件組合在一起以形成更大的結構。

常見的結構型模式包括：

1. 適配器模式（Adapter）：將一個類別的接口轉換成客戶端希望的另一個接口，使得接口不相容的類別可以一起工作。
2. 橋接模式（Bridge）：將抽象部分與它的實作部分分離，使得它們可以獨立變化。
3. 組合模式（Composite）：將物件組合成樹狀結構以表示「部分-整體」的層次結構。
4. 裝飾器模式（Decorator）：動態地為一個物件添加新的功能，而不改變其結構。
5. 外觀模式（Facade）：為子系統中的一組接口提供一個統一的接口，從而簡化子系統的使用。
6. 享元模式（Flyweight）：透過共享細粒度物件以支援大量物件的高效使用。

適配器模式（Adapter）

適配器模式透過將一個類別的介面轉換為客戶端期望的另一個接口，使得本來不相容的類別能夠一起工作。例如，假設你有一個類別 OldSystem，它有一個接口 DoOldWork()，而現在需要透過 NewSystem 的介面 DoNewWork() 來使用它。

package main import "fmt" // OldSystem 舊系統介面type OldSystem struct{} func (o *OldSystem) DoOldWork() { fmt.Println("做舊系統的工作") } // NewSystem 新系統介面type NewSystem intertype {face DoNewWork() } // Adapter 適配器type Adapter struct { oldSystem *OldSystem } func (a *Adapter) DoNewWork() { a.oldSystem.DoOldWork() } func main() { oldSys := &OldSystem{} adapter . oldSystem: oldSys} adapter.DoNewWork() }

3.3 行為型模式

行為型模式關注物件之間的職責分配和溝通方式。這類模式不僅關注類別和物件的結構，也關注它們之間的互動行為，以便更靈活和有效率地完成任務。

常見的行為型模式包括：

1. 觀察者模式（Observer）：定義物件之間一對多的依賴關係，當一個物件的狀態改變時，所有依賴它的物件都會自動收到通知。
2. 策略模式（Strategy）：定義一系列演算法，將每個演算法封裝起來，並使它們可以互相替換。
3. 命令模式（Command）：將請求封裝成對象，使得可以使用不同的請求、佇列或日誌來參數化其他對象。
4. 狀態模式（State）：允許物件根據其內部狀態改變行為。
5. 責任鏈模式（Chain of Responsibility）：將請求的發送者和接收者解耦，透過將請求傳遞給一系列處理對象，直到有一個對象處理請求為止。

觀察者模式（Observer）

觀察者模式用於定義物件之間的依賴關係。它使得一個物件的狀態改變時，其所依賴的物件會自動接收到更新通知。這種模式經常用於事件處理系統，如GUI框架、訊息廣播系統等。

package main import "fmt" // Observer 是觀察者介面type Observer interface { Update(string) } // ConcreteObserver 是特定的觀察者實作type ConcreteObserver struct { name string } func (o *ConcreteObserver) Update(message string) { fmt.Printf("%s 收到訊息: %s\n", o.name, message) } // Subject 是被觀察的物件type Subject struct { observers []Observer } func (s *Subject) Attach(observer Observer) { s.observers = append(s.observers, observer) } func (s *Subject) Detach(observer Observer) { for i, obs := range s.observers { if obs == observer { s.observers = append(sobservers { if obs == observer { s.observers = append(sobservers { if obs == observer { s.observers = append(sobservers { if obs == observer { s.observers = append(sobservers { if obs == observer { s.observers = append(s .observers[:i], s.observers[i+1:]...) break } } } func (s *Subject) NotifyObservers(message string) { for _, observer := range s.observers { observer.Update (message) } } func main() { subject := &Subject{} observer1 := &ConcreteObserver{name: "觀察者1"} observer2 := &ConcreteObserver{name: "觀察者2"} subject.Attach(observer1) subject. Attach(observer2) subject.NotifyObservers("設計模式學習中") subject.Detach(observer1) subject.NotifyObservers("進度更新：已完成") }

4. 設計模式的應用實例

• 單例模式在資料庫連線管理的應用：單例模式常用於管理資料庫連線池，因為系統只需要一個全域的連線池實例來處理資料庫的連線和釋放。

• 觀察者模式在事件監聽上的應用：在GUI應用程式中，按鈕的點擊事件通常透過觀察者模式來處理。按鈕會維護一個觀察者列表，當用戶點擊按鈕時，它會通知所有註冊的觀察者執行相應的操作。

5. 結論

設計模式是軟體開發中的重要工具。它們為常見的設計問題提供了標準化的解決方案，幫助開發者寫出更具可讀性、可擴展性和可維護性的程式碼。透過理解和應用不同類型的設計模式，開發者可以更輕鬆地解決複雜的軟體設計問題，並提高開發效率。

設計模式並不是一成不變的規則，而是一種靈活的設計方法。在實際專案中，開發者可以根據需求選擇合適的設計模式，也可以根據實際情況進行適當調整。掌握設計模式後，你會發現軟體開發中的許多問題都能輕鬆解決，程式碼也變得更簡潔、更清晰。

參考連結：

• Design Patterns - Gang of Four (GoF)
• Singleton Pattern in Go
• Factory Method in Go
• Observer Pattern in Go