golang設計模式之簡單工廠模式

簡單工廠模式

wiki: 簡單工廠模式並不屬於 GoF 23 個經典設計模式，但一般將它做爲學習其餘工廠模式的基礎，它的設計思想很簡單，其基本流程以下：

首先將須要建立的各類不一樣對象（例如各類不一樣的 Chart 對象）的相關代碼封裝到不一樣的類中，這些類稱爲具體產品類，而將它們公共的代碼進行抽象和提取後封裝在一個抽象產品類中，每個具體產品類都是抽象產品類的子類；而後提供一個工廠類用於建立各類產品，在工廠類中提供一個建立產品的工廠方法，該方法能夠根據所傳入的參數不一樣建立不一樣的具體產品對象；客戶端只需調用工廠類的工廠方法並傳入相應的參數便可獲得一個產品對象。

簡單工廠模式定義以下：

簡單工廠模式（Simple Factory Pattern）：定義一個工廠類，它能夠根據參數的不一樣返回不一樣類的實例，被建立的實例一般都具備共同的父類。由於在簡單工廠模式中用於建立實例的方法是靜態（static）方法，所以簡單工廠模式又被稱爲靜態工廠方法（Static Factory Method）模式，它屬於類建立型模式。

簡單工廠模式的要點在於：當你須要什麼，只須要傳入一個正確的參數，就能夠獲取你所須要的對象，而無須知道其建立細節。簡單工廠模式結構比較簡單，其核心是工廠類的設計，其結構如圖所示

上面都是我抄來的...

大概要作的事情就是，當咱們想要建立一個對象的時候，調用同一個方法，傳入不一樣的參數就能夠返回給咱們不一樣的對象了

固然，前提是這些對象對應的類都實現了相同的接口

例如：

咱們建立一個工廠結構體，而且建立一個產品接口，工廠能夠建立產品，只要在工廠的某個方法中傳入不一樣的參數，就能夠返回實現產品接口的不一樣的對象，

1. 建立工廠結構體:

type Factory struct {
   }
複製代碼

2. 建立產品接口，這裏爲了方便，只寫了一個方法，請根據本身的須要擴展

type Product interface {
   	create()
   }
複製代碼

3. 建立兩個產品：產品1和產品2，它們實現了產品接口:

// 產品1，實現產品接口
type Product1 struct {
}

func (p1 Product1) create() {
  	fmt.Println("this is product 1")
}

// 產品2，實現產品接口
type Product2 struct {
}

func (p1 Product2) create() {
  	fmt.Println("this is product 2")
}

複製代碼

2. 爲工廠結構體添加一個方法用於生產產品（實例化對象）:

func (f Factory) Generate(name string) Product {
     switch name {
     case "product1":
  	   return Product1{}
     case "product2":
  	   return Product2{}
     default:
  	   return nil
     }
 }   
複製代碼

3. 這樣就能夠經過傳入不一樣的方法獲得不一樣的產品實例了:

// 建立一個工廠類，在應用中能夠將這個工廠類實例做爲一個全局變量
    	factory := new(Factory)
    
    	// 在工廠類中傳入不一樣的參數，獲取不一樣的實例
    	p1 := factory.Generate("product1")
    	p1.create() // output: this is product 1
    
    	p2 := factory.Generate("product2")
    	p2.create() // output: this is product 2
複製代碼

上面的例子只是爲了解釋工廠模式的思想而設置的最簡單的例子，下面舉一個在實際中應用的例子：

bingo-log 是一個go語言的日誌包，能夠自定義日誌輸出格式，這裏就用到了簡單工廠模式，全部實現了 Connector 接口的結構體均可以做爲參數傳入日誌結構體中，達到自定義輸出格式的目的

項目地址: bingo-log

思路解析: 基於go開發日誌處理包

請直接去項目 README.md 中查看使用方法，去思路解析中查看總體的設計思路

下面說說工廠模式的優缺點:

• 優勢: 工廠類是整個工廠模式的核心，咱們只須要傳入給定的信息，就能夠建立所需實例，在多人協做的時候，無需知道對象之間的內部依賴，能夠直接建立，有利於整個軟件體系結構的優化

• 缺點: 工廠類中包含了全部實例的建立邏輯，一旦這個工廠類出現問題，全部實例都會受到影響，而且，工廠類中生產的產品都基於一個共同的接口，一旦要添加不一樣種類的產品，這就會增長工廠類的複雜度，將不一樣種類的產品混合在一塊兒，違背了單一職責，系統的靈活性和可維護性都會下降，而且當新增產品的時候，必需要修改工廠類，違背了『系統對擴展開放，對修改關閉』的原則

因此咱們還有更加複雜的設計模式去適應更加複雜的系統~

且聽下回分解~ ~

此文章的源碼都在這個倉庫中： golang設計模式

打個廣告，推薦一下本身寫的 go web框架 bingo,求star，求PR ~