Golang設計模式工廠模式實戰寫法範例詳解

2022-08-29 14:01:28

拆出主機板

今天帶大家看一下怎麼用 Go 寫工廠模式的程式碼，我們來學習一個實戰案例。這個寫法筆者日常經常使用，能夠很有效地幫助大家實現 Separation of Concerns。

主機板就是一個程式的主流程。比如我們要基於一份學習資料來消化，吸收知識。我們可能有下面幾步流程：

準備好筆電；
開啟資料；
閱讀資料內容，思考並記錄關鍵點到筆電上；
做資料裡包含的練習題；
歸納總結，驗證掌握程度。

這個資料，可以是紙質書籍，可以是電子書，可以是某個平臺的專欄，形式有很多，但我們不 care，因為在主題流程中，只需要它是個資料，有資料的能力即可。

換句話說，我們把資料轉換成一個 interface，定義如下：

type KnowledgeMaterial interface{
	GetContent() string
	GetExercises() []string
}

能給我們主體內容，能給我們練習題，滿足這兩點就夠了。

所以，主機板本質上是不 care 具體這個資料是什麼的。

擴充套件則是基於 interface 的實現，或者類比一下 adapter，就是個介面卡。我們可以定義出來 Book, Ebook, Column 各種各樣的擴充套件，它們都實現了這個 KnowledgeMaterial 介面。

很多同學寫程式碼的時候，拆不開主機板，不知道自己的核心流程是什麼，這一點是非常重要的。拆不出來【主流程】，就意味著你需要針對某個實體實現邏輯時，直接依賴了這個【實現】。

比如我們上面的 case，沒有 KnowledgeMaterial 介面，你的流程變成了，翻開紙質書第一頁，看看目錄，然後翻到第一章，開始閱讀書上的文字。。。。

這是很可怕的一件事，意味著一旦結構變了，你的程式碼是不可能適配的。你會需要各種 if else 來判斷到底是哪種型別。如果後來又來了一種學習資料，叫做【視訊課程】，這時候怎麼辦呢？

沒有頁供你翻了，你面對的實體變成了視訊內容，想要適配，就勢必不是容易的事。

所以，大家一定要練習這個能力，遇到問題，思考自己的主流程是什麼，拆出主機板，然後明確你對業務實體的訴求是什麼，能否抽象化。

是一個實現了KnowledgeMaterial 介面的任意實體就 ok？還是必須得是 Book 這個具體的結構體才 ok？

如果你需要的只是個介面，能夠抽象簡化，就儘量用我們今天要說的工廠模式來做，這樣你的主流程心智負擔會小很多，此後新增擴充套件成本也很小。

工廠模式流程

抽象出對實體的能力要求，變成介面；
實現工廠，支援介面卡註冊，支援根據型別獲取對應的介面實現；
主流程只依賴介面完成；
將你的擴充套件，變成 adapter 介面卡，實現介面所要求的的能力；
將你的介面卡通過第二步裡提到的方法，註冊到工廠裡。

這樣的好處就在於，主機板和擴充套件隔離，新增擴充套件的時候，只需要新增，不需要動主流程，不需要動其他擴充套件，避免了一大堆 if else 的寫法。

程式碼實戰

我們結合一開始提到的 KnowledgeMaterial 介面來簡單範例一下。

抽象能力，定義介面

type KnowledgeMaterial interface{
	GetContent() string
	GetExercises() []string
}

實現工廠，支援註冊和獲取實現

新建一個 factory.go 檔案，填充如下內容：

type KnowledgeAdapterFactory struct {
	sync.RWMutex
	adapters []KnowledgeAdapter
}
var (
	knowledgeAdapterFactory = KnowledgeAdapterFactory{
		adapters: []KnowledgeAdapter{},
	}
)
// RegisterKnowledgeAdapter 註冊新的知識資料介面卡
func RegisterKnowledgeAdapter(adapter KnowledgeAdapter) {
	knowledgeAdapterFactory.Lock()
	knowledgeAdapterFactory.adapters = append(knowledgeAdapterFactory.adapters, adapter)
        knowledgeAdapterFactory.Unlock()
}
// GetAllKnowledgeAdapters 獲取所有知識資料介面卡
func GetAllKnowledgeAdapters() []KnowledgeAdapter {
	return knowledgeAdapterFactory.adapters
}

主流程只依賴介面完成

重點關注和 adapter 相關的邏輯，其他部分省略：

func LearnKnowledge() {
	//準備好筆電
	notes := openNotesForWrite()
	for _, adapter := range GetAllKnowledgeAdapters() {
		content := adapter.GetContent()
		// 閱讀資料內容，思考並記錄關鍵點到筆電上
		writeNotes(content)
		// 做資料裡包含的練習題
		for _, ex := range adapter.GetExercises() {
			doExecise(ex)
		}
	}
	// 歸納總結，驗證掌握程度
	summary()
}

擴充套件 => 介面卡，實現介面

新建一個包：book，用於實現紙質書籍的介面卡。在其中新建 adapter.go 檔案，填充如下程式碼

type Adapter struct {}
func (a *Adapter) GetContent() string {
	return "xxx"
}
func (a *Adapter) GetExercises() []string {
	return []string{"xxx"}
}

註冊介面卡到工廠裡

這裡寫法其實相對靈活，很多人會選擇直接在工廠定義的 factory.go 寫註冊邏輯，我個人不太喜歡這樣。這就意味著每次新增介面卡，都需要動工廠。

比較推薦直接在介面卡的 init() 函數中完成註冊，然後在 main 函數啟動時 import 包進來，就執行了 init 函數。

這樣寫的好處在於當你新增一個擴充套件的時候，主流程和工廠都不需要動，只新增檔案就好。

我們可以把上面的 adapter.go 新增一個函數即可：

type Adapter struct {}
func init() {
	RegisterKnowledgeAdapter(&Adapter{})
}
func (a *Adapter) GetContent() string {
	return "xxx"
}
func (a *Adapter) GetExercises() []string {
	return []string{"xxx"}
}