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

silsuer在掘金發表於2019-03-02
Golang設計模式

簡單工廠模式

wiki: 簡單工廠模式並不屬於 GoF 23 個經典設計模式，但通常將它作為學習其他工廠模式的基礎，它的設計思想很簡單，其基本流程如下：

首先將需要建立的各種不同物件（例如各種不同的 Chart 物件）的相關程式碼封裝到不同的類中，這些類稱為具體產品類，而將它們公共的程式碼進行抽象和提取後封裝在一個抽象產品類中，每一個具體產品類都是抽象產品類的子類；然後提供一個工廠類用於建立各種產品，在工廠類中提供一個建立產品的工廠方法，該方法可以根據所傳入的引數不同建立不同的具體產品物件；客戶端只需呼叫工廠類的工廠方法並傳入相應的引數即可得到一個產品物件。

簡單工廠模式定義如下：

簡單工廠模式（Simple Factory Pattern）：定義一個工廠類，它可以根據引數的不同返回不同類的例項，被建立的例項通常都具有共同的父類。因為在簡單工廠模式中用於建立例項的方法是靜態（static）方法，因此簡單工廠模式又被稱為靜態工廠方法（Static Factory Method）模式，它屬於類建立型模式。

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

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

上面都是我抄來的...

大概要做的事情就是，當我們想要建立一個物件的時候，呼叫同一個方法，傳入不同的引數就可以返回給我們不同的物件了

當然，前提是這些物件對應的類都實現了相同的介面

例如：

我們建立一個工廠結構體，並且建立一個產品介面，工廠可以建立產品，只要在工廠的某個方法中傳入不同的引數，就可以返回實現產品介面的不同的物件，

  1. 建立工廠結構體:
   type Factory struct {
   }
複製程式碼
  1. 建立產品介面，這裡為了方便，只寫了一個方法，請根據自己的需要擴充套件
   type Product interface {
   	create()
   }
複製程式碼
  1. 建立兩個產品：產品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")
}

複製程式碼
  1. 為工廠結構體新增一個方法用於生產產品（例項化物件）:
 func (f Factory) Generate(name string) Product {
     switch name {
     case "product1":
  	   return Product1{}
     case "product2":
  	   return Product2{}
     default:
  	   return nil
     }
 }   
複製程式碼
  1. 這樣就可以通過傳入不同的方法得到不同的產品例項了:
      // 建立一個工廠類，在應用中可以將這個工廠類例項作為一個全域性變數
    	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 ~

相關文章