简单工厂适合单一维度的对象创建，抽象工厂用于多维度产品族的一致性构建。简单工厂根据参数决定实例类型，适用于种类少、结构固定的场景，如日志记录器的创建；抽象工厂则提供一组接口创建相关对象，确保产品族一致性，如跨平台ui控件的构建。两者区别在于适用对象数量、扩展性和一致性保证，选型应基于业务需求与扩展方向。
在 Golang 项目中，工厂模式是构建复杂对象时常用的设计模式之一。它通过封装对象的创建逻辑，提升代码的可维护性和扩展性。其中，简单工厂和抽象工厂是最常见的两种实现方式，但它们适用的场景有所不同。
简单工厂：适合单一维度的对象创建
简单工厂并不是 GoF 提出的标准设计模式，但在实际开发中非常常见。它通过一个工厂类根据传入的参数决定创建哪一种产品类的实例。
使用场景：
- 对象种类较少，且都在同一层级结构中
- 创建逻辑集中、不频繁变化
- 调用方只需要知道输入参数，不需要关心具体实现
举个例子，假设我们要根据不同类型创建日志记录器（Logger）：
立即学习“go语言免费学习笔记（深入）”；
type Logger interface {
Log(msg string)
}
type ConsoleLogger struct{}
func (l ConsoleLogger) Log(msg string) {
fmt.Println("Console:", msg)
}
type FileLogger struct{}
func (l FileLogger) Log(msg string) {
// 写入文件逻辑
}
func NewLogger(logType string) Logger {
switch logType {
case "console":
return ConsoleLogger{}
case "file":
return FileLogger{}
default:
panic("Unsupported logger type")
}
}这种方式简单直接，适用于小型系统或模块内部使用。
抽象工厂：应对多维度的产品族
当系统中存在多个产品族，并且这些产品之间需要保持一致性时，就需要使用抽象工厂模式。它提供了一组用于创建一系列相关或依赖对象的接口，而无需指定其具体类。
使用场景：
- 存在多个产品族，比如不同平台下的 UI 控件（WindowsButton + WindowsTextBox vs MacButton + MacTextBox）
- 需要确保一组相关对象一起使用，避免混用
- 希望隐藏产品族的实现细节，仅暴露接口
例如，在一个跨平台的应用中，我们可能需要创建不同的组件：
type Button interface {
Click()
}
type TextBox interface {
Input(text string)
}
// Windows 工厂
type WindowsFactory struct{}
func (f WindowsFactory) CreateButton() Button {
return WindowsButton{}
}
func (f WindowsFactory) CreateTextBox() TextBox {
return WindowsTextBox{}
}
// Mac 工厂
type MacFactory struct{}
func (f MacFactory) CreateButton() Button {
return MacButton{}
}
func (f MacFactory) CreateTextBox() TextBox {
return MacTextBox{}
}这样做的好处是，调用者只需选择一个工厂，就能获得一整套兼容的对象组合。
简单工厂 vs 抽象工厂：区别与选型建议
| 特点 | 简单工厂 | 抽象工厂 |
|---|---|---|
| 适用对象数量 | 少，单一维度 | 多，多个产品族 |
| 扩展性 | 新增类型需修改工厂 | 新增产品族只需新增工厂 |
| 一致性保证 | 不涉及 | 强制统一产品族 |
| 实现复杂度 | 简单 | 相对复杂 |
建议如下：
- 如果只是创建几个简单的对象，优先考虑简单工厂。
- 如果产品之间有明确的“家族”关系，或者未来可能扩展多个产品族，抽象工厂更适合。
- 抽象工厂虽然结构清晰，但也带来了更多接口和结构定义，不要为了用模式而用模式。
- 在 Golang 中，由于没有继承机制，抽象工厂更依赖于接口组合来实现，因此要注意接口设计的合理性。
总的来说，简单工厂适合快速上手和小规模使用，抽象工厂适合大型系统或需要良好扩展性的场景。两者各有优劣，关键在于理解当前业务需求和未来的扩展方向。
基本上就这些。
