如何在Go中实现工厂模式_Go工厂模式代码结构解析

Go工厂模式用接口+函数返回具体实例解耦创建与使用，应返回明确接口而非interface{}，通过注册表替代if/else，支持选项函数或配置结构体传参，注册需线程安全，工厂应轻量无副作用。

Go 语言没有类和继承，所谓“工厂模式”不是靠抽象基类+子类实现的，而是用接口 + 函数返回具体结构体实例的方式达成——核心是解耦创建逻辑与使用逻辑。

为什么 Go 的工厂函数通常返回 interface{}

工厂函数返回 interface{} 是常见误区。正确做法是返回一个明确的接口类型（比如 Shape），让调用方只依赖行为契约，不感知具体结构体。返回 interface{} 会丢失类型信息，后续必须强制类型断言，反而增加耦合和 panic 风险。

实际做法：

• 先定义接口（如 type Shape interface { Area() float64 }）
• 工厂函数签名应为 func NewShape(kind string) Shape，而非 func NewShape(kind string) interface{}
• 每个具体类型（Circle、Rectangle）实现该接

  

  口

如何避免工厂函数里堆砌 if/else 判断

当产品种类增多，if kind == "circle" { return &Circle{} } 这类硬编码分支会难以维护。更可持续的做法是用注册表 + 映射：

示例关键结构：

var creators = make(map[string]func() Shape)

func Register(name string, creator func() Shape) {
    creators[name] = creator
}

func NewShape(kind string) Shape {
    if c, ok := creators[kind]; ok {
        return c()
    }
    panic("unknown shape: " + kind)
}

使用时提前注册：

func init() {
    Register("circle", func() Shape { return &Circle{} })
    Register("rect", func() Shape { return &Rectangle{} })
}

工厂是否需要接收配置参数？怎么传才安全

如果具体类型初始化需要参数（比如 Circle{Radius: 5.0}），工厂函数不应直接接收原始字段（如 func NewCircle(radius float64) Shape），否则每新增字段都要改签名。推荐两种方式：

• 用选项函数（functional options）：定义 type Option func(*Circle)，工厂接收变长 Option 参数，内部按需应用
• 用配置结构体：定义 type CircleConfig struct { Radius float64; Unit string }，工厂接收 CircleConfig，保持函数签名稳定

避免把 map[string]interface{} 当万能参数传入工厂——它绕过了编译检查，运行时易出错且无法被 IDE 提示。

并发环境下工厂函数要注意什么

注册表（如上文的 creators map）若在运行时动态注册，多个 goroutine 同时调用 Register 会引发 panic。必须加锁或限定仅在 init() 中注册。

工厂函数本身通常是无状态的，但若内部缓存了资源（如复用连接池、预分配对象池），就要注意：

• 缓存读写需同步（sync.RWMutex 或 sync.Map）
• 避免在工厂里做耗时操作（如磁盘 I/O、网络请求），否则会拖慢所有调用方

多数情况下，工厂就该是个轻量、纯内存、无副作用的构造函数——复杂初始化逻辑应该下沉到具体类型的 NewXXX() 方法里，而不是塞进工厂分支中。