工厂模式
一般情况下，工厂模式分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂。不过，在GoF的《设计模式》一书中，它将简单工厂模式看作是工厂方法模式的一种特例，所以工厂模式只被分成了工厂方法和抽象工厂两类。

在这三种细分的工厂模式中，简单工厂、工厂方法原理比较简单，在实际的项目中也比较常用。我们这里来重点的介绍下这两种。

简单工厂模式(Simple Factory)
定义
定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。

因为在简单工厂模式用于创建实例的方法是静态的方法，因此简单工厂模式又被称为静态工厂方法模式，它属于类创建型模式。

优点
工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。

客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。

通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

缺点
由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。

使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。

系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。

简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

适用范围
工厂类负责创建的对象比较少，客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心。

代码实现

package main

import "fmt"

func main() {
	f := getFruit("apple")
	fmt.Println(f.Fruit())
}

type FruitFactory interface {
	Fruit() string
}

func getFruit(t string) FruitFactory {
	switch t {
	case "apple":
		return &apple{}
	case "banana":
		return &banana{}
	}

	return nil
}

type apple struct{}

func (*apple) Fruit() string {
	return "我是苹果，我很好吃"
}

type banana struct{}

func (*banana) Fruit() string {
	return "我是香蕉，我最好吃了"
}

总结下：

主要是通过 if 来判断逻辑，当我们有新的实现需要加入，只需要添加对应的 if 判断就好了。

UML 类图

工厂方法模式(Factory Method)
定义
工厂方法模式（英语：Factory method pattern）是一种实现了“工厂”概念的面向对象设计模式。就像其他创建型模式一样，它也是处理在不指定对象具体类型的情况下创建对象的问题。工厂方法模式的实质是“定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。工厂方法让类的实例化推迟到子类中进行。”

优点
一个调用者想创建一个对象，只要知道其名称就可以了。

扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

屏蔽产品的具体实现，调用者只关心产品的接口。

缺点
每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

适用范围
当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。

代码实现

package main

import "fmt"

func main() {
	apple := appleFactory{}
	fmt.Println(apple.Fruit())

	banana := bananaFactory{}
	fmt.Println(banana.Fruit())
}

type Fruit interface {
	Fruit() string
}

type appleFactory struct{}

func (*appleFactory) Fruit() string {
	return "我是苹果，我很好吃"
}

type bananaFactory struct{}

func (*bananaFactory) Fruit() string {
	return "我是香蕉，我最好吃了"
}

总结：

工厂方法模式实现的时，客户端需要决定实例化哪一个工厂来决定选择那种水果，还是需要判断的，只不过这个判断交给客户端进行了。简单工厂是修改工厂类，这里只需要修改客户端。

UML 类图

抽象工厂模式(Abstract Factory)
定义
抽象工厂模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

优点
抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。

易于交换产品系列，由于具体的工场类，在使用的时候只需要在应用中初始化一次，所以改变工厂就很简单，只需要改变具体地工厂就能使用对应的配置信息。

它让具体地创建过程和客户端分离，客户端通过他们的抽象接口操作实例，产品的具体类名也和具体工厂分离，不会出现在客户端代码中。

缺点
抽象工厂模式在于难于应付“新对象”的需求变动。难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几乎确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

适用范围
1.一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

2.这个系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

3.同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。（比如：Intel主板必须使用Intel CPU、Intel芯片组）

4.系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

代码实现

package main

import "fmt"

func main() {
	f := WuhanFruitFactory{}
	b := f.ChooseApple()
	b.Fruit()
}

type FruitInterface interface {
	ChooseApple() ProductInterface
	ChooseBanana() ProductInterface
}

type ProductInterface interface {
	Fruit()
}

type HainanApple struct {
}

func (h HainanApple) Fruit() {
	fmt.Println("我是苹果，来自海南")
}

type HainanBanana struct {
}

func (h HainanBanana) Fruit() {
	fmt.Println("我是香蕉，来自海南")
}

type WuhanApple struct {
}

func (w WuhanApple) Fruit() {
	fmt.Println("我是苹果，来自武汉")
}

type WuhanBanana struct {
}

func (w WuhanBanana) Fruit() {
	fmt.Println("我是香蕉，来自武汉")
}

type WuhanFruitFactory struct {
}

func (w WuhanFruitFactory) ChooseApple() ProductInterface {
	return WuhanApple{}
}

func (w WuhanFruitFactory) ChooseBanana() ProductInterface {
	return WuhanBanana{}
}

type HainanFruitFactory struct {
}

func (gd HainanFruitFactory) ChooseApple() ProductInterface {
	return HainanApple{}
}

func (gd HainanFruitFactory) ChooseBanana() ProductInterface {
	return HainanBanana{}
}

UML 类图

总结：

这里抽象出了两个工厂，然后每个工厂中实现自己的方法。

客户端在使用的时候只需要在应用中初始化一次，所以改变工厂就很简单，只需要改变具体地工厂就能使用对应的配置信息。

针对抽象工厂模式，我们会声明那个工厂，当然进一步扩展，我们可以结合依赖注入，上游将工厂注入进来，下游根据注入的工厂进行初始化，这样就更加灵活了，依赖注入模式，我们后面在接着分析。