简单工厂适合对象种类不多的情况，通过统一的工厂函数根据参数返回不同实例，如创建dog和cat对象；抽象工厂用于创建一组相互关联的对象且存在多种变体，例如根据不同操作系统创建对应的ui控件。两者核心区别在于处理对象关系的复杂度：简单工厂仅支持单一类别，新增类型需修改工厂逻辑；抽象工厂支持多组合扩展，符合开闭原则但结构更复杂。选择时若对象种类少且变化小用简单工厂；若有多组关联对象并可能扩展则用抽象工厂。
在 Go 语言中，工厂模式是构建复杂对象时常用的手段之一。很多人会混淆“简单工厂”和“抽象工厂”，其实它们解决的问题不同，适用场景也有差异。本文不讲理论堆砌，而是从实际使用角度出发，说清楚怎么用、什么时候用。
简单工厂：适合对象种类不多的情况
简单工厂并不是 GoF 的 23 种设计模式之一，但在实际开发中非常常见。它通过一个统一的“工厂函数”来创建对象，根据传入参数返回不同的实例。
举个例子，假设你有一个 Animal 接口，有 Dog 和 Cat 两个实现：
立即学习“go语言免费学习笔记（深入）”；
type Animal interface {
Speak()
}
type Dog struct{}
func (d Dog) Speak() { fmt.Println("Woof!") }
type Cat struct{}
func (c Cat) Speak() { fmt.Println("Meow!") }你可以写一个工厂函数来创建：
func NewAnimal(animalType string) Animal {
switch animalType {
case "dog":
return Dog{}
case "cat":
return Cat{}
default:
panic("unknown animal type")
}
}使用建议：
- 当你只需要创建一组相关或依赖对象中的一个时，简单工厂足够。
- 不需要复杂的结构，代码清晰易读。
- 缺点是违反开闭原则，每新增一种类型都要改工厂逻辑。
抽象工厂：应对多系列产品的创建场景
如果你要支持多个产品族（比如不同操作系统下的 UI 控件），这时候抽象工厂就派上用场了。
抽象工厂定义的是一个接口，每个具体工厂实现这个接口，负责创建一整套相关的产品。
例如，定义两个控件接口 Button 和 Checkbox，然后为 Windows 和 MacOS 各做一个实现工厂。
type Button interface {
Render()
}
type Checkbox interface {
Render()
}
type UIFactory interface {
CreateButton() Button
CreateCheckbox() Checkbox
}然后分别实现 WindowsFactory 和 MacOSFactory，各自返回对应的控件。
使用建议：
- 适用于创建一组相互关联的对象，且这些对象存在多种变体。
- 更加灵活，符合开闭原则，新增产品族只需添加新工厂。
- 结构相对复杂，不适合小项目。
如何选择：简单工厂 vs 抽象工厂？
两者的核心区别在于处理对象的关系复杂度。以下是几个判断依据：
- 如果只有一类产品，并且变化不大，用简单工厂。
- 如果有多个类，彼此之间有关联，而且可能会扩展出多个组合，用抽象工厂。
- 抽象工厂更像是“工厂的工厂”，它关注的是“家族”关系。
- 简单工厂更像是一种封装，隐藏创建细节。
举个生活化的对比：
- 简单工厂像是一个卖饮料的自动售货机，输入编号给你可乐或雪碧；
- 抽象工厂则像是根据不同节日准备的礼包，春节礼包包含春联和灯笼，圣诞节礼包包含袜子和圣诞树。
在 Go 中实现工厂模式的小技巧
Go 没有构造函数，但可以通过函数返回结构体实例来模拟。这里有几个实用建议：
- 工厂函数命名习惯用
NewXXX，如NewUser,NewLogger。 - 如果对象初始化过程复杂，可以结合配置参数或选项函数（functional options）一起使用。
- 对于抽象工厂，可以配合接口+实现的方式组织代码结构，提高可测试性。
- 工厂函数尽量不要做太多业务逻辑，保持职责单一。
基本上就这些。工厂模式本身不复杂，但用好它需要对业务模型有一定理解。选对模式，才能写出干净、可维护的代码。
