用Go语言实现建造者模式---工厂模式

设计模式中的工厂模式是我们编写代码时常用的一种建造型模式，用于创建指定类的实例。

在不使用设计模式的时候，我们是怎么创建类的实例的呢？

别多想，这个问题没坑，就是我们写代码时直接用 new 关键字，直接创建实例。比如 Java 语言里是通过 new 关键字直接调用类的构造方法，完成实例的创建。

class  Person {}

Person p1 = new Person();

而像 Go 语言这类，虽说是非面向对象语言，但也提供了创建类型实例指针的 new 方法。

type Person struct{}

var p1 Person 
p1 = new(Person)

那既然能直接 new ，有人肯定会问“那为什么还要用设计模式啊？而且听说工厂模式里边还能分出好几种工厂”。解答这个问题并不难，因为我们总是会把一些已经定型的业务处理逻辑抽象成各种项目里的公共类库，这样才能找到抓手，让产品开发形成闭环......。

上面的黑话，大家一定不要学，在公司用容易有不好的结果...我这里只是为了提升点喜感，下面用正经话再说一遍。

于是乎，聪明的你一定会想到，这时候，我让类库再暴露出一个 NewXXX 之类的方法，这个 NewXXX 方法能够根据条件生产出具体类型的实例返回给业务程序用。如果你能想到这里，恭喜你，这个时候你已经用上工厂模式了。

有时候就是这样，在写代码的时候，不知不觉地就用上设计模式了，虽然你可能还不知道。等我们把设计模式用熟后，自然就能有意识地写出更好的代码。

设计模式里工厂模式一共可以提炼成三类工厂：

• 简单工厂

• 工厂方法

• 抽象工厂

这三类工厂模式的抽象度依次提高，像上面给大家举的例子，你不知不觉用上的就是“简单工厂”这种设计模式，随着这种流程定型的类库越来越复杂，要求的抽象度变高后，我们可能还会用到后面两种工厂模式。这里我就用一些例子，把这三种工厂模式给大家分析一下。

简单工厂

Go 语言没有构造函数一说，所以一般会定义 NewXXX 函数来初始化相关类。NewXXX 函数返回接口时就是简单工厂模式。

// Printer 简单工厂要返回的接口类型
type Printer interface {
 Print(name string) string
}

程序通过简单工厂向客户端提供需要的语种的打印机。

func NewPrinter(lang string) Printer {
 switch lang {
 case "cn":
  return new(CnPrinter)
 case "en":
  return new(EnPrinter)
 default:
  return new(CnPrinter)
 }
}

目前这个场景里我们先提供两个语种的打印机，他们都是 Printer 接口的具体实现类型。

// CnPrinter 是 Printer 接口的实现，它说中文
type CnPrinter struct {}

func (*CnPrinter) Print(name string) string {
 return fmt.Sprintf("你好, %s", name)
}

// EnPrinter 是 Printer 接口的实现，它说中文
type EnPrinter struct {}

func (*EnPrinter) Print(name string) string {
 return fmt.Sprintf("Hello, %s", name)
}

这个场景下，工厂、产品接口、具体产品类的关系可以用下面这个图表示。

 

 客户端只需要告诉工厂想要哪个语种的打印机产品，工厂就会把产品给返回给客户端。

printer := NewPrinter("en")
fmt.Println(printer.Print("Bob"))

简单工厂模式主要包含3个角色。

• 简单工厂：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。

• 抽象产品：是简单工厂创建的所有对象的抽象父类/接口，负责描述所有实例的行为。

• 具体产品：是简单工厂模式的创建目标

在这段代码中，我们可以将上述三个角色对应到简单工厂模式的描述中：

1. 简单工厂：在这个代码中，NewPrinter函数充当了简单工厂的角色。它负责根据不同的输入条件（lang），创建具体产品的实例对象（CnPrinter或EnPrinter）。NewPrinter方法可以被外界直接调用，并根据需要创建所需的产品对象。

2. 抽象产品：在这个代码中，Printer接口就是抽象产品。它定义了Print方法，描述了所有产品都应该具备的行为，即打印输出一段文字。Printer接口是所有具体产品的抽象父类/接口，它定义了产品的公共方法，但不涉及具体的实现。

3. 具体产品：在这个代码中，CnPrinter和EnPrinter是具体产品。它们分别实现了Printer接口中定义的Print方法，并且提供了特定语言的输出。CnPrinter用于输出中文，EnPrinter用于输出英文。

简单工厂的优点是，简单，缺点嘛，如果具体产品扩产，就必须修改工厂内部，增加Case，一旦产品过多就会导致简单工厂过于臃肿，为了解决这个问题，才有了下一级别的工厂模式--工厂方法。

工厂方法

工厂方法模式（Factory Method Pattern）又叫作多态性工厂模式，指的是定义一个创建对象的接口，但由实现这个接口的工厂类来决定实例化哪个产品类，工厂方法把类的实例化推迟到子类中进行。

在工厂方法模式中，不再由单一的工厂类生产产品，而是由工厂类的子类实现具体产品的创建。因此，当增加一个产品时，只需增加一个相应的工厂类的子类, 以解决简单工厂生产太多产品时导致其内部代码臃肿（switch … case分支过多）的问题。

下面举个简单的例子来理解工厂方法的设计思想，考虑有这样一个生产计算器的工厂，每类计算器产品都由一个子工厂负责生产。

注意：Go中没有继承，所以这里说的工厂子类，其实是直接实现工厂接口的具体工厂类。

现在我们假定程序可以生产两类计算器，加法计算器和乘法计算器，也就是在工厂方法模式中，存在两个子类工厂。

//PlusOperatorFactory 是 PlusOperator 加法运算器的工厂类
type PlusOperatorFactory struct{}

func (pf *PlusOperatorFactory) Create() MathOperator {
 return &PlusOperator{
  BaseOperator: &BaseOperator{},
 }
}

// MultiOperatorFactory 是乘法运算器产品的工厂
type MultiOperatorFactory struct {}

func (mf *MultiOperatorFactory) Create() MathOperator{
 return &MultiOperator{
  BaseOperator: &BaseOperator{},
 }
}

这个场景下，工厂、产品接口、具体产品类的关系可以用下面这个图表示。

 类图--工厂方法

测试运行--客户端使用子类工厂创建产品实例。

func main() {
 var factory OperatorFactory
 var mathOp MathOperator
 factory = &PlusOperatorFactory{}
 mathOp = factory.Create()
 mathOp.SetOperandB(3)
 mathOp.SetOperandA(2)
 fmt.Printf("Plus operation reuslt: %d\n", mathOp.ComputeResult())

 factory= &MultiOperatorFactory{}
 mathOp = factory.Create()
 mathOp.SetOperandB(3)
 mathOp.SetOperandA(2)
 fmt.Printf("Multiple operation reuslt: %d\n", mathOp.ComputeResult())
}

工厂方法模式的优点

• 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。

• 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

工厂方法模式的缺点

• 类的个数容易过多，增加复杂度。

• 增加了系统的抽象性和理解难度。

• 只能生产一种产品，此弊端可使用抽象工厂模式解决。

无论是简单工厂还是工厂方法都只能生产一种产品，如果工厂需要创建生态里的多个产品，就需要更进一步，使用第三级的工厂模式--抽象工厂。

抽象工厂

抽象工厂模式：用于创建一系列相关的或者相互依赖的对象。

为了更清晰地理解工厂方法模式和抽象工厂模式的区别，我们举一个品牌产品生态的例子。

比如智能家居领域多家公司，现在有华为和小米，他们的工厂除了生产我们熟知的手机外，还会生产电视、空调这种家电设备。

假如我们有幸作为他们工厂智能化管理软件的供应商，在软件系统里要对工厂进行抽象，这个时候就不能再用工厂方法这种设计模式了，因为工厂方法只能用来生产一种产品。

我们先看一下使用类图表示的这个抽象工厂抽象多品牌--多产品的形态。

 

下面我们用代码简单实现一个抽象工厂，这个工厂能生成智能电视和空调，当然产品的功能在代码里比较简单，就是输出一条相应的信息。

目前抽象工厂有两个实际工厂类一个是华为的工厂，一个是小米的工厂，他们用来实际生产自家的产品设备。

type AbstractFactory interface {
 CreateTelevision() ITelevision
 CreateAirConditioner() IAirConditioner
}

type ITelevision interface {
 Watch()
}

type IAirConditioner interface {
 SetTemperature(int)
}

type HuaWeiFactory struct{}

func (hf *HuaWeiFactory) CreateTelevision() ITelevision {
 return &HuaWeiTV{}
}
func (hf *HuaWeiFactory) CreateAirConditioner() IAirConditioner {
 return &HuaWeiAirConditioner{}
}

type HuaWeiTV struct{}

func (ht *HuaWeiTV) Watch() {
 fmt.Println("Watch HuaWei TV")
}

type HuaWeiAirConditioner struct{}

func (ha *HuaWeiAirConditioner) SetTemperature(temp int) {
 fmt.Printf("HuaWei AirConditioner set temperature to %d ℃\n", temp)
}

type MiFactory struct{}

func (mf *MiFactory) CreateTelevision() ITelevision {
 return &MiTV{}
}
func (mf *MiFactory) CreateAirConditioner() IAirConditioner {
 return &MiAirConditioner{}
}

type MiTV struct{}

func (mt *MiTV) Watch() {
 fmt.Println("Watch HuaWei TV")
}

type MiAirConditioner struct{}

func (ma *MiAirConditioner) SetTemperature(temp int) {
 fmt.Printf("Mi AirConditioner set temperature to %d ℃\n", temp)
}


func main() {
 var factory AbstractFactory
 var tv ITelevision
 var air IAirConditioner

 factory = &HuaWeiFactory{}
 tv = factory.CreateTelevision()
 air = factory.CreateAirConditioner()
 tv.Watch()
 air.SetTemperature(25)

 factory = &MiFactory{}
 tv = factory.CreateTelevision()
 air = factory.CreateAirConditioner()
 tv.Watch()
 air.SetTemperature(26)
}

同样抽象工厂也具备工厂方法把产品的创建推迟到工厂子类去做的特性，假如未来加入了 VIVO 的产品，我们就可以通过再创建 VIVO 工厂子类来扩展。 

对于抽象工厂我们可以总结以下几点：

• 当系统所提供的工厂所需生产的具体产品并不是一个简单的对象，而是多个位于不同产品等级结构中属于不同类型的具体产品时需要使用抽象工厂模式。

• 抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。

• 抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建 。

• 当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、有效率。

抽象工厂模式的优点

• 当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品族。

• 抽象工厂增强了程序的可扩展性，对于新产品族的增加，只需实现一个新的具体工厂即可，不需要对已有代码进行修改，符合开闭原则。

抽象工厂模式的缺点

• 规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口。

• 增加了系统的抽象性和理解难度。

最后

我们用几个较为简单的例子和大家一起学习了下三个工厂模式各自的场景和优缺点，实际使用的时候项目一开始需求还没那么明确的时候推荐还是先用简单工厂，等我们业务理解更透彻后如果确实需要再升级到工厂方法也不迟。

抽象工厂也是，如果确定引入产品生态的概念才能更好地进行领域建模，再开始使用抽象工厂也不迟。