Go 实现常用的设计模式 - 工厂模式

工厂模式 ( factory )

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

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

别多想，这个问题没坑，就是我们写代码时直接用 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 接口。

package main

import "fmt"

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

// 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)
}

// 打印机的构造函数
func NewPrinter(lang string) Printer {
	switch lang {
	case "cn":
		return new(CnPrinter)
	case "en":
		return new(EnPrinter)
	default:
		return new(CnPrinter)
	}
}

func main() {
	printer := NewPrinter("en")
	fmt.Println(printer.Print("Bob"))
}

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

• 简单工厂：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
• 抽象产品：是简单工厂创建的所有对象的抽象父类/接口，负责描述所有实例的行为。
• 具体产品：是简单工厂模式的创建目标。

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

工厂方法

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

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

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

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

package main

import "fmt"

// OperatorFactory 工厂接口，由具体工厂类来实现
type OperatorFactory interface {
	Create() MathOperator
}

// MathOperator 实际产品实现的接口--表示数学运算器应该有哪些行为
type MathOperator interface {
	SetOperandA(int)
	SetOperandB(int)
	ComputeResult() int
}

// BaseOperator 是所有 Operator 的基类
// 封装公用方法，因为Go不支持继承，具体Operator类
// 只能组合它来实现类似继承的行为表现。
type BaseOperator struct {
	operandA, operandB int
}

func (o *BaseOperator) SetOperandA(operand int) {
	o.operandA = operand
}

func (o *BaseOperator) SetOperandB(operand int) {
	o.operandB = operand
}

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

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

//PlusOperator 实际的产品类--加法运算器
type PlusOperator struct {
	*BaseOperator
}

//ComputeResult 计算并获取结果
func (p *PlusOperator) ComputeResult() int {
	return p.operandA + p.operandB
}

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

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

// MultiOperator 实际的产品类--乘法运算器
type MultiOperator struct {
	*BaseOperator
}
func (m *MultiOperator) ComputeResult() int {
	return m.operandA * m.operandB
}

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())
}

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

工厂方法模式的优点

• 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
• 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

工厂方法模式的缺点

• 类的个数容易过多，增加复杂度。
• 增加了系统的抽象性和理解难度。
• 只能生产一种产品，此弊端可使用抽象工厂模式解决。

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

抽象工厂

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

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

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

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

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

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

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

package main

import "fmt"

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 工厂子类来扩展。

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

• 当系统所提供的工厂所需生产的具体产品并不是一个简单的对象，而是多个位于不同产品等级结构中属于不同类型的具体产品时需要使用抽象工厂模式。
• 抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。
• 抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建 。
• 当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、有效率。

抽象工厂模式的优点
当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品族。抽象工厂增强了程序的可扩展性，对于新产品族的增加，只需实现一个新的具体工厂即可，不需要对已有代码进行修改，符合开闭原则。

抽象工厂模式的缺点
规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口。增加了系统的抽象性和理解难度。

最后

我们用几个较为简单的例子和大家一起学习了下三个工厂模式各自的场景和优缺点，实际使用的时候项目一开始需求还没那么明确的时候推荐还是先用简单工厂，等我们业务理解更透彻后如果确实需要再升级到工厂方法也不迟。抽象工厂也是，如果确定引入产品生态的概念才能更好地进行领域建模，再开始使用抽象工厂也不迟。