簡易工廠模式(Easy Factory Pattern)
簡易工廠模式提供一個創建對象實例的功能，而無需關心其具體實現。被創建實例的類型可以是接口，抽象類，也可以是具體的類。
看個例子
type Api interface {
Test()
}
type ApiTester struct{
}
func (a *ApiTester) Test() {
fmt.println("this is api tester 1")
}
func main() {
var api = new ApiTester()
api.Test() // this is api tester 1
}
上述代碼看起來有問題嗎？看起來沒有。
但是注意到在main調用的時候，知道了具體聲明的類，也知道了具體的接口。接口的思想是“封裝隔離”，而實現類ApiTester應該是被接口Api封裝並同調用方隔離開的，也就是說在調用的時候不應該讓其知道我聲明的具體類是什麼。
意圖
選擇實現。簡單工廠模式的目的在於爲調用方選擇相應的實現，將調用方和實現之間解耦。即使具體實現發生了變化，調用方也不用做修改
組成部分
-
Product
需要實現的抽象產品接口
-
ConcrectProduct
對產品接口實現的具體產品類
-
Factory
定義一個工廠對象，該對象的方式實現的對產品接口的選擇實現方法
範例代碼
範例代碼爲我們要創建一個漢堡，但是我們只要輸入我們要的漢堡類型就可以了，不需要知道這個漢堡是怎麼做出來的。
總結
- 本章介紹的簡易工廠模式也可成爲靜態工廠模式，可以讓客戶端指定需要生產的產品，但是不需要知道這個產品是如何生產的，生產的具體細節隱藏在工廠中。
- 簡單工廠的方法大多是用來創建接口的，但是仔細分析就會發現，真正能實現功能的是具體的實現類，這些實現類是已經做好的，並不是真的要靠簡單工廠來創造出來的，簡單工廠的方法無外乎就是：實現了選擇一個合適的實現類來使用。
- 如果想要完全封裝隔離具體實現，讓外部只能通過接口來操作封裝體，那麼可以選用簡單通常，讓客戶端通過工廠來獲取相應的接口，而無需關心具體的實現。
缺點
如果需要在方法裏寫很多與對象創建有關的業務代碼，而且需要的創建的對象還不少的話，我們要在這個簡單工廠類裏編寫很多個方法，每個方法裏都得寫很多相應的業務代碼，而每次增加子類或者刪除子類對象的創建都需要打開這簡單工廠類來進行修改。這會導致這個簡單工廠類很龐大臃腫、耦合性高，而且增加、刪除某個子類對象的創建都需要打開簡單工廠類來進行修改代碼也違反了開-閉原則。
資料來源
改。這會導致這個簡單工廠類很龐大臃腫、耦合性高，而且增加、刪除某個子類對象的創建都需要打開簡單工廠類來進行修改代碼也違反了開-閉原則。
資料來源