拆出主板

今天帶大家看一下怎么用 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"}
}

小結

工廠模式是一個很簡單，容易上手的寫法，重點還是在于大家要區分開主板和擴展，通過注冊方式填充適配器，而不是通過 if else 來區分。希望今天介紹的寫法對你有幫助，這里還可以有很多變形，本質是類似的。