Go语言工厂模式如何实现_Go语言工厂模式教程【高效】-Golang-PHP中文网

go 的工厂模式应基于接口+函数，返回具体接口类型而非 interface{}，通过注册机制实现解耦与开闭原则；抽象工厂用于多组件协同场景，需配合依赖注入避免资源泄漏。

go语言工厂模式如何实现_go语言工厂模式教程【高效】

Go 语言没有类和继承，所谓“工厂模式”不是靠抽象父类+子类重写实现的，而是用接口 + 函数返回具体结构体来模拟——直接返回 interface{} 或更合理的自定义接口类型，才是符合 Go 习惯的做法。

为什么不能照搬 Java/C# 的工厂写法

Go 不支持构造函数重载、不支持方法重写、也没有“new”关键字。试图用空接口 interface{} 接收不同结构体再做类型断言，不仅丢失编译期类型安全，还容易在运行时 panic。真正的 Go 工厂，核心是「接口定义行为，函数封装创建逻辑」。

常见错误现象：
– 写了个 func NewFactory(type string) interface{}，调用后必须 if v, ok := obj.(MyStruct); ok { ... } 才能干活
– 所有具体类型都暴露给调用方，工厂失去解耦意义
– 每次新增类型都要改工厂函数，违反开闭原则

正确做法：先定义统一接口（如 type Worker interface{ Do() }）
每个具体类型实现该接口（无需显式声明 implements）
工厂函数返回该接口类型，而非 interface{}
工厂内部用 map 或 switch 分发，但调用方只依赖接口

简单工厂：用 map + sync.Once 避免重复注册

适合类型不多、创建逻辑轻量的场景。重点不是“多态”，而是把 new 操作集中管理，方便加日志、指标或初始化校验。

type Creator func() Worker
<p>var (
creators = make(map[string]Creator)
once     sync.Once
)</p><p>func Register(name string, c Creator) {
once.Do(func() { creators = make(map[string]Creator) })
creators[name] = c
}</p><p>func NewWorker(name string) (Worker, error) {
if c, ok := creators[name]; ok {
return c(), nil
}
return nil, fmt.Errorf("unknown worker type: %s", name)
}
</p>

使用场景：
– CLI 工具中按子命令名创建不同处理器
– HTTP 路由中按 content-type 创建不同解析器

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

注册必须在 init() 或 main 启动早期完成，否则 NewWorker 可能返回 nil
不要在 Register 里做耗时初始化，工厂函数 Creator 应该是轻量的
map 非并发安全，如果需热加载，改用 sync.RWMutex 包裹读写

抽象工厂：按环境/配置返回整套组件

当不止一个对象需要协同工作（比如 Logger + Cache + DB），且不同环境（dev/staging/prod）组合不同实现时，才需要抽象工厂。它本质是一组工厂函数的集合，不是单个函数。

type ServiceFactory interface {
    NewLogger() Logger
    NewCache() Cache
    NewDB() DB
}
<p>type DevFactory struct{}
func (DevFactory) NewLogger() Logger { return &DevLogger{} }
func (DevFactory) NewCache() Cache { return &MemoryCache{} }
func (DevFactory) NewDB() DB       { return &MockDB{} }</p><p>func NewFactory(env string) ServiceFactory {
switch env {
case "prod": return ProdFactory{}
case "staging": return StagingFactory{}
default: return DevFactory{}
}
}
</p>

参数差异：
– env 通常来自配置文件或环境变量，不应硬编码在代码里
– 各实现类型之间无继承关系，只是恰好实现了同一组方法

抽象工厂的接口方法应尽量窄：只暴露当前上下文真正需要的能力
避免让工厂返回指针以外的类型（如 struct 值），防止意外拷贝
如果某环境只需替换其中一个组件（如只换 DB），考虑用选项模式（func Option(*Config)）替代整套工厂

工厂和依赖注入（DI）怎么选

工厂解决的是“如何创建”，DI 解决的是“如何传递依赖”。两者常一起用，但别混淆：工厂函数本身不该持有全局状态，也不该去 resolve 其他服务——那已经是 DI 容器的事了。

容易踩的坑：
– 在工厂里直接调用 logrus.New() 或 redis.NewClient()，导致无法 mock 测试
– 把数据库连接池、HTTP 客户端等长生命周期对象塞进工厂每次 new，造成资源泄漏
– 用工厂替代配置解析，把 "redis://..." 字符串硬编码在 switch 分支里