摘要：設計模式（Design Pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解並且保證代碼可靠性。
本文分享自華為雲社區《快來，這里有23種設計模式的Go語言實現》，原文作者：元閏子 。
前言
從1995年GoF提出23種設計模式到現在，25年過去了，設計模式依舊是軟件領域的熱門話題。在當下，如果你不會一點設計模式，都不好意思說自己是一個合格的程序員。設計模式通常被定義為：
設計模式（Design Pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解並且保證代碼可靠性。
從定義上看，設計模式其實是一種經驗的總結，是針對特定問題的簡潔而優雅的解決方案。既然是經驗總結，那么學習設計模式最直接的好處就在於可以站在巨人的肩膀上解決軟件開發過程中的一些特定問題。然而，學習設計模式的最高境界是習得其中解決問題所用到的思想，當你把它們的本質思想吃透了，也就能做到即使已經忘掉某個設計模式的名稱和結構，也能在解決特定問題時信手拈來。
好的東西有人吹捧，當然也會招黑。設計模式被抨擊主要因為以下兩點：
1、設計模式會增加代碼量，把程序邏輯變得復雜。這一點是不可避免的，但是我們並不能僅僅只考慮開發階段的成本。最簡單的程序當然是一個函數從頭寫到尾，但是這樣后期的維護成本會變得非常大；而設計模式雖然增加了一點開發成本，但是能讓人們寫出可復用、可維護性高的程序。引用《軟件設計的哲學》里的概念，前者就是戰術編程，后者就是戰略編程，我們應該對戰術編程Say No！
2、濫用設計模式。這是初學者最容易犯的錯誤，當學到一個模式時，恨不得在所有的代碼都用上，從而在不該使用模式的地方刻意地使用了模式，導致了程序變得異常復雜。其實每個設計模式都有幾個關鍵要素：適用場景、解決方法、優缺點。模式並不是萬能葯，它只有在特定的問題上才能顯現出效果。所以，在使用一個模式前，先問問自己，當前的這個場景適用這個模式嗎？
《設計模式》一書的副標題是“可復用面向對象軟件的基礎”，但並不意味着只有面向對象語言才能使用設計模式。模式只是一種解決特定問題的思想，跟語言無關。就像Go語言一樣，它並非是像C++和Java一樣的面向對象語言，但是設計模式同樣適用。本系列文章將使用Go語言來實現GoF提出的23種設計模式，按照創建型模式（Creational Pattern）、結構型模式（Structural Pattern）和行為型模式（Behavioral Pattern）三種類別進行組織，文本主要介紹其中的創建型模式。
單例模式（Singleton Pattern）
簡述
單例模式算是23中設計模式里最簡單的一個了，它主要用於保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
在程序設計中，有一些對象通常我們只需要一個共享的實例，比如線程池、全局緩存、對象池等，這種場景下就適合使用單例模式。
但是，並非所有全局唯一的場景都適合使用單例模式。比如，考慮需要統計一個API調用的情況，有兩個指標，成功調用次數和失敗調用次數。這兩個指標都是全局唯一的，所以有人可能會將其建模成兩個單例SuccessApiMetric和FailApiMetric。按照這個思路，隨着指標數量的增多，你會發現代碼里類的定義會越來越多，也越來越臃腫。這也是單例模式最常見的誤用場景，更好的方法是將兩個指標設計成一個對象ApiMetric下的兩個實例ApiMetic success和ApiMetic fail。
如何判斷一個對象是否應該被建模成單例？
通常，被建模成單例的對象都有“中心點”的含義，比如線程池就是管理所有線程的中心。所以，在判斷一個對象是否適合單例模式時，先思考下，這個對象是一個中心點嗎？
Go實現
在對某個對象實現單例模式時，有兩個點必須要注意：（1）限制調用者直接實例化該對象；（2）為該對象的單例提供一個全局唯一的訪問方法。
對於C++/Java而言，只需把類的構造函數設計成私有的，並提供一個static方法去訪問該類點唯一實例即可。但對於Go語言來說，即沒有構造函數的概念，也沒有static方法，所以需要另尋出路。
我們可以利用Go語言package的訪問規則來實現，將單例結構體設計成首字母小寫，就能限定其訪問范圍只在當前package下，模擬了C++/Java中的私有構造函數；再在當前package下實現一個首字母大寫的訪問函數，就相當於static方法的作用了。
在實際開發中，我們經常會遇到需要頻繁創建和銷毀的對象。頻繁的創建和銷毀一則消耗CPU，二則內存的利用率也不高，通常我們都會使用對象池技術來進行優化。考慮我們需要實現一個消息對象池，因為是全局的中心點，管理所有的Message實例，所以將其實現成單例，實現代碼如下：
package msgpool ... // 消息池 type messagePool struct { pool *sync.Pool } // 消息池單例 var msgPool = &messagePool{ // 如果消息池里沒有消息，則新建一個Count值為0的Message實例 pool: &sync.Pool{New: func() interface{} { return &Message{Count: 0} }}, } // 訪問消息池單例的唯一方法 func Instance() *messagePool { return msgPool } // 往消息池里添加消息 func (m *messagePool) AddMsg(msg *Message) { m.pool.Put(msg) } // 從消息池里獲取消息 func (m *messagePool) GetMsg() *Message { return m.pool.Get().(*Message) } ...
測試代碼如下：
package test ... func TestMessagePool(t *testing.T) { msg0 := msgpool.Instance().GetMsg() if msg0.Count != 0 { t.Errorf("expect msg count %d, but actual %d.", 0, msg0.Count) } msg0.Count = 1 msgpool.Instance().AddMsg(msg0) msg1 := msgpool.Instance().GetMsg() if msg1.Count != 1 { t.Errorf("expect msg count %d, but actual %d.", 1, msg1.Count) } } // 運行結果 === RUN TestMessagePool --- PASS: TestMessagePool (0.00s) PASS
以上的單例模式就是典型的“餓漢模式”，實例在系統加載的時候就已經完成了初始化。對應地，還有一種“懶漢模式”，只有等到對象被使用的時候，才會去初始化它，從而一定程度上節省了內存。眾所周知，“懶漢模式”會帶來線程安全問題，可以通過普通加鎖，或者更高效的雙重檢驗鎖來優化。對於“懶漢模式”，Go語言有一個更優雅的實現方式，那就是利用sync.Once，它有一個Do方法，其入參是一個方法，Go語言會保證僅僅只調用一次該方法。
// 單例模式的“懶漢模式”實現 package msgpool ... var once = &sync.Once{} // 消息池單例，在首次調用時初始化 var msgPool *messagePool // 全局唯一獲取消息池pool到方法 func Instance() *messagePool { // 在匿名函數中實現初始化邏輯，Go語言保證只會調用一次 once.Do(func() { msgPool = &messagePool{ // 如果消息池里沒有消息，則新建一個Count值為0的Message實例 pool: &sync.Pool{New: func() interface{} { return &Message{Count: 0} }}, } }) return msgPool } ...
建造者模式（Builder Pattern）
簡述
在程序設計中，我們會經常遇到一些復雜的對象，其中有很多成員屬性，甚至嵌套着多個復雜的對象。這種情況下，創建這個復雜對象就會變得很繁瑣。對於C++/Java而言，最常見的表現就是構造函數有着長長的參數列表：
MyObject obj = new MyObject(param1, param2, param3, param4, param5, param6, ...)
而對於Go語言來說，最常見的表現就是多層的嵌套實例化：
obj := &MyObject{ Field1: &Field1 { Param1: &Param1 { Val: 0, }, Param2: &Param2 { Val: 1, }, ... }, Field2: &Field2 { Param3: &Param3 { Val: 2, }, ... }, ... }
上述的對象創建方法有兩個明顯的缺點：（1）對對象使用者不友好，使用者在創建對象時需要知道的細節太多；（2）代碼可讀性很差。
針對這種對象成員較多，創建對象邏輯較為繁瑣的場景，就適合使用建造者模式來進行優化。
建造者模式的作用有如下幾個：
1、封裝復雜對象的創建過程，使對象使用者不感知復雜的創建邏輯。
2、可以一步步按照順序對成員進行賦值，或者創建嵌套對象，並最終完成目標對象的創建。
3、對多個對象復用同樣的對象創建邏輯。
其中，第1和第2點比較常用，下面對建造者模式的實現也主要是針對這兩點進行示例。
Go實現
考慮如下的一個Message結構體，其主要有Header和Body組成：
package msg ... type Message struct { Header *Header Body *Body } type Header struct { SrcAddr string SrcPort uint64 DestAddr string DestPort uint64 Items map[string]string } type Body struct { Items []string } ...
如果按照直接的對象創建方式，創建邏輯應該是這樣的：
// 多層的嵌套實例化 message := msg.Message{ Header: &msg.Header{ SrcAddr: "192.168.0.1", SrcPort: 1234, DestAddr: "192.168.0.2", DestPort: 8080, Items: make(map[string]string), }, Body: &msg.Body{ Items: make([]string, 0), }, } // 需要知道對象的實現細節 message.Header.Items["contents"] = "application/json" message.Body.Items = append(message.Body.Items, "record1") message.Body.Items = append(message.Body.Items, "record2")
雖然Message結構體嵌套的層次不多，但是從其創建的代碼來看，確實存在對對象使用者不友好和代碼可讀性差的缺點。下面我們引入建造者模式對代碼進行重構：
package msg ... // Message對象的Builder對象 type builder struct { once *sync.Once msg *Message } // 返回Builder對象 func Builder() *builder { return &builder{ once: &sync.Once{}, msg: &Message{Header: &Header{}, Body: &Body{}}, } } // 以下是對Message成員對構建方法 func (b *builder) WithSrcAddr(srcAddr string) *builder { b.msg.Header.SrcAddr = srcAddr return b } func (b *builder) WithSrcPort(srcPort uint64) *builder { b.msg.Header.SrcPort = srcPort return b } func (b *builder) WithDestAddr(destAddr string) *builder { b.msg.Header.DestAddr = destAddr return b } func (b *builder) WithDestPort(destPort uint64) *builder { b.msg.Header.DestPort = destPort return b } func (b *builder) WithHeaderItem(key, value string) *builder { // 保證map只初始化一次 b.once.Do(func() { b.msg.Header.Items = make(map[string]string) }) b.msg.Header.Items[key] = value return b } func (b *builder) WithBodyItem(record string) *builder { b.msg.Body.Items = append(b.msg.Body.Items, record) return b } // 創建Message對象，在最后一步調用 func (b *builder) Build() *Message { return b.msg }
測試代碼如下：
package test ... func TestMessageBuilder(t *testing.T) { // 使用消息建造者進行對象創建 message := msg.Builder(). WithSrcAddr("192.168.0.1"). WithSrcPort(1234). WithDestAddr("192.168.0.2"). WithDestPort(8080). WithHeaderItem("contents", "application/json"). WithBodyItem("record1"). WithBodyItem("record2"). Build() if message.Header.SrcAddr != "192.168.0.1" { t.Errorf("expect src address 192.168.0.1, but actual %s.", message.Header.SrcAddr) } if message.Body.Items[0] != "record1" { t.Errorf("expect body item0 record1, but actual %s.", message.Body.Items[0]) } } // 運行結果 === RUN TestMessageBuilder --- PASS: TestMessageBuilder (0.00s) PASS
從測試代碼可知，使用建造者模式來進行對象創建，使用者不再需要知道對象具體的實現細節，代碼可讀性也更好。
工廠方法模式（Factory Method Pattern）
簡述
工廠方法模式跟上一節討論的建造者模式類似，都是將對象創建的邏輯封裝起來，為使用者提供一個簡單易用的對象創建接口。兩者在應用場景上稍有區別，建造者模式更常用於需要傳遞多個參數來進行實例化的場景。
使用工廠方法來創建對象主要有兩個好處：
1、代碼可讀性更好。相比於使用C++/Java中的構造函數，或者Go中的{}來創建對象，工廠方法因為可以通過函數名來表達代碼含義，從而具備更好的可讀性。比如，使用工廠方法productA := CreateProductA()創建一個ProductA對象，比直接使用productA := ProductA{}的可讀性要好。
2、與使用者代碼解耦。很多情況下，對象的創建往往是一個容易變化的點，通過工廠方法來封裝對象的創建過程，可以在創建邏輯變更時，避免霰彈式修改。
工廠方法模式也有兩種實現方式：（1）提供一個工廠對象，通過調用工廠對象的工廠方法來創建產品對象；（2）將工廠方法集成到產品對象中（C++/Java中對象的static方法，Go中同一package下的函數）
Go實現
考慮有一個事件對象Event，分別有兩種有效的時間類型Start和End：
package event ... type Type uint8 // 事件類型定義 const ( Start Type = iota End ) // 事件抽象接口 type Event interface { EventType() Type Content() string } // 開始事件，實現了Event接口 type StartEvent struct{ content string } ... // 結束事件，實現了Event接口 type EndEvent struct{ content string } ...
1、按照第一種實現方式，為Event提供一個工廠對象，具體代碼如下：
package event ... // 事件工廠對象 type Factory struct{} // 更具事件類型創建具體事件 func (e *Factory) Create(etype Type) Event { switch etype { case Start: return &StartEvent{ content: "this is start event", } case End: return &EndEvent{ content: "this is end event", } default: return nil } }
測試代碼如下：
package test ... func TestEventFactory(t *testing.T) { factory := event.Factory{} e := factory.Create(event.Start) if e.EventType() != event.Start { t.Errorf("expect event.Start, but actual %v.", e.EventType()) } e = factory.Create(event.End) if e.EventType() != event.End { t.Errorf("expect event.End, but actual %v.", e.EventType()) } } // 運行結果 === RUN TestEventFactory --- PASS: TestEventFactory (0.00s) PASS
2、按照第二種實現方式，分別給Start和End類型的Event單獨提供一個工廠方法，代碼如下：
package event ... // Start類型Event的工廠方法 func OfStart() Event { return &StartEvent{ content: "this is start event", } } // End類型Event的工廠方法 func OfEnd() Event { return &EndEvent{ content: "this is end event", } }
測試代碼如下：
package event ... func TestEvent(t *testing.T) { e := event.OfStart() if e.EventType() != event.Start { t.Errorf("expect event.Start, but actual %v.", e.EventType()) } e = event.OfEnd() if e.EventType() != event.End { t.Errorf("expect event.End, but actual %v.", e.EventType()) } } // 運行結果 === RUN TestEvent --- PASS: TestEvent (0.00s) PASS
抽象工廠模式（Abstract Factory Pattern）
簡述
在工廠方法模式中，我們通過一個工廠對象來創建一個產品族，具體創建哪個產品，則通過swtich-case的方式去判斷。這也意味着該產品組上，每新增一類產品對象，都必須修改原來工廠對象的代碼；而且隨着產品的不斷增多，工廠對象的職責也越來越重，違反了單一職責原則。
抽象工廠模式通過給工廠類新增一個抽象層解決了該問題，如上圖所示，FactoryA和FactoryB都實現·抽象工廠接口，分別用於創建ProductA和ProductB。如果后續新增了ProductC，只需新增一個FactoryC即可，無需修改原有的代碼；因為每個工廠只負責創建一個產品，因此也遵循了單一職責原則。
Go實現
考慮需要如下一個插件架構風格的消息處理系統，pipeline是消息處理的管道，其中包含了input、filter和output三個插件。我們需要實現根據配置來創建pipeline ，加載插件過程的實現非常適合使用工廠模式，其中input、filter和output三類插件的創建使用抽象工廠模式，而pipeline的創建則使用工廠方法模式。
各類插件和pipeline的接口定義如下：
package plugin ... // 插件抽象接口定義 type Plugin interface {} // 輸入插件，用於接收消息 type Input interface { Plugin Receive() string } // 過濾插件，用於處理消息 type Filter interface { Plugin Process(msg string) string } // 輸出插件，用於發送消息 type Output interface { Plugin Send(msg string) }
package pipeline ... // 消息管道的定義 type Pipeline struct { input plugin.Input filter plugin.Filter output plugin.Output } // 一個消息的處理流程為 input -> filter -> output func (p *Pipeline) Exec() { msg := p.input.Receive() msg = p.filter.Process(msg) p.output.Send(msg) }
接着，我們定義input、filter、output三類插件接口的具體實現：
package plugin ... // input插件名稱與類型的映射關系，主要用於通過反射創建input對象 var inputNames = make(map[string]reflect.Type) // Hello input插件，接收“Hello World”消息 type HelloInput struct {} func (h *HelloInput) Receive() string { return "Hello World" } // 初始化input插件映射關系表 func init() { inputNames["hello"] = reflect.TypeOf(HelloInput{}) }
package plugin ... // filter插件名稱與類型的映射關系，主要用於通過反射創建filter對象 var filterNames = make(map[string]reflect.Type) // Upper filter插件，將消息全部字母轉成大寫 type UpperFilter struct {} func (u *UpperFilter) Process(msg string) string { return strings.ToUpper(msg) } // 初始化filter插件映射關系表 func init() { filterNames["upper"] = reflect.TypeOf(UpperFilter{}) }
package plugin ... // output插件名稱與類型的映射關系，主要用於通過反射創建output對象 var outputNames = make(map[string]reflect.Type) // Console output插件，將消息輸出到控制台上 type ConsoleOutput struct {} func (c *ConsoleOutput) Send(msg string) { fmt.Println(msg) } // 初始化output插件映射關系表 func init() { outputNames["console"] = reflect.TypeOf(ConsoleOutput{}) }
然后，我們定義插件抽象工廠接口，以及對應插件的工廠實現：
package plugin ... // 插件抽象工廠接口 type Factory interface { Create(conf Config) Plugin } // input插件工廠對象，實現Factory接口 type InputFactory struct{} // 讀取配置，通過反射機制進行對象實例化 func (i *InputFactory) Create(conf Config) Plugin { t, _ := inputNames[conf.Name] return reflect.New(t).Interface().(Plugin) } // filter和output插件工廠實現類似 type FilterFactory struct{} func (f *FilterFactory) Create(conf Config) Plugin { t, _ := filterNames[conf.Name] return reflect.New(t).Interface().(Plugin) } type OutputFactory struct{} func (o *OutputFactory) Create(conf Config) Plugin { t, _ := outputNames[conf.Name] return reflect.New(t).Interface().(Plugin) }
最后定義pipeline的工廠方法，調用plugin.Factory抽象工廠完成pipelien對象的實例化：
package pipeline ... // 保存用於創建Plugin的工廠實例，其中map的key為插件類型，value為抽象工廠接口 var pluginFactories = make(map[plugin.Type]plugin.Factory) // 根據plugin.Type返回對應Plugin類型的工廠實例 func factoryOf(t plugin.Type) plugin.Factory { factory, _ := pluginFactories[t] return factory } // pipeline工廠方法，根據配置創建一個Pipeline實例 func Of(conf Config) *Pipeline { p := &Pipeline{} p.input = factoryOf(plugin.InputType).Create(conf.Input).(plugin.Input) p.filter = factoryOf(plugin.FilterType).Create(conf.Filter).(plugin.Filter) p.output = factoryOf(plugin.OutputType).Create(conf.Output).(plugin.Output) return p } // 初始化插件工廠對象 func init() { pluginFactories[plugin.InputType] = &plugin.InputFactory{} pluginFactories[plugin.FilterType] = &plugin.FilterFactory{} pluginFactories[plugin.OutputType] = &plugin.OutputFactory{} }
測試代碼如下：
package test ... func TestPipeline(t *testing.T) { // 其中pipeline.DefaultConfig()的配置內容見【抽象工廠模式示例圖】 // 消息處理流程為 HelloInput -> UpperFilter -> ConsoleOutput p := pipeline.Of(pipeline.DefaultConfig()) p.Exec() } // 運行結果 === RUN TestPipeline HELLO WORLD --- PASS: TestPipeline (0.00s) PASS
原型模式（Prototype Pattern）
簡述
原型模式主要解決對象復制的問題，它的核心就是clone()方法，返回Prototype對象的復制品。在程序設計過程中，往往會遇到有一些場景需要大量相同的對象，如果不使用原型模式，那么我們可能會這樣進行對象的創建：新創建一個相同對象的實例，然后遍歷原始對象的所有成員變量， 並將成員變量值復制到新對象中。這種方法的缺點很明顯，那就是使用者必須知道對象的實現細節，導致代碼之間的耦合。另外，對象很有可能存在除了對象本身以外不可見的變量，這種情況下該方法就行不通了。
對於這種情況，更好的方法就是使用原型模式，將復制邏輯委托給對象本身，這樣，上述兩個問題也都迎刃而解了。
Go實現
還是以建造者模式一節中的Message作為例子，現在設計一個Prototype抽象接口：
package prototype ... // 原型復制抽象接口 type Prototype interface { clone() Prototype } type Message struct { Header *Header Body *Body } func (m *Message) clone() Prototype { msg := *m return &msg }
測試代碼如下：
package test ... func TestPrototype(t *testing.T) { message := msg.Builder(). WithSrcAddr("192.168.0.1"). WithSrcPort(1234). WithDestAddr("192.168.0.2"). WithDestPort(8080). WithHeaderItem("contents", "application/json"). WithBodyItem("record1"). WithBodyItem("record2"). Build() // 復制一份消息 newMessage := message.Clone().(*msg.Message) if newMessage.Header.SrcAddr != message.Header.SrcAddr { t.Errorf("Clone Message failed.") } if newMessage.Body.Items[0] != message.Body.Items[0] { t.Errorf("Clone Message failed.") } } // 運行結果 === RUN TestPrototype --- PASS: TestPrototype (0.00s) PASS
總結
本文主要介紹了GoF的23種設計模式中的5種創建型模式，創建型模式的目的都是提供一個簡單的接口，讓對象的創建過程與使用者解耦。其中，單例模式主要用於保證一個類僅有一個實例，並提供一個訪問它的全局訪問點；建造者模式主要解決需要創建對象時需要傳入多個參數，或者對初始化順序有要求的場景；工廠方法模式通過提供一個工廠對象或者工廠方法，為使用者隱藏了對象創建的細節；抽象工廠模式是對工廠方法模式的優化，通過為工廠對象新增一個抽象層，讓工廠對象遵循單一職責原則，也避免了霰彈式修改；原型模式則讓對象復制更加簡單。