Go中工厂方法模式用函数类型或结构体替代抽象类，核心是将NewXxx作为可替换依赖；推荐type ProductFactory func() Product，参数化构造可用结构体工厂或闭包，避免在New中做初始化校验，多产品类型优先用字符串分发的简单工厂。
工厂方法模式在 Go 里没有“抽象类”怎么办
Go 没有继承和抽象类，所以不能照搬 Java/C# 的工厂方法定义方式。它的核心不是“子类重写创建方法”，而是“用函数值或接口解耦对象构造逻辑”。关键在于把 NewXxx 函数作为可替换的依赖项传入，而不是硬编码在业务逻辑里。
常见错误是强行模仿类结构，比如定义一个空接口加一堆 func() interface{} 方法，结果既难测试又难扩展。真正实用的做法是：让工厂本身成为函数类型，或封装为结构体字段。
- 推荐定义工厂类型：
type ProductFactory func() Product - 业务代码只依赖
ProductFactory，不关心具体实现 - 测试时可直接传入闭包模拟不同返回，无需 mock 接口
- 避免为工厂单独建 interface，除非真需要多个方法（如带参数的构造）
如何让工厂支持带参数的构造场景
很多实际需求中，产品创建需要运行时参数（如配置、ID、上下文），而标准工厂方法模式通常假设无参。Go 里最自然的解法是把参数提前绑定，或用函数工厂生成工厂。
例如数据库连接工厂需传 host/port，不应写成 func NewDBFactory(host, port string) func() DB——这会让调用方重复构造工厂。更合理的是：
立即学习“go语言免费学习笔记（深入）”；
type DBFactory struct {
host string
port int
}
func (f DBFactory) New() DB {
return &realDB{addr: fmt.Sprintf("%s:%d", f.host, f.port)}
}- 结构体工厂便于复用和组合（比如嵌入配置或日志器）
- 若参数极简且临时，用闭包更轻量：
func(host, port string) ProductFactory { return func() Product { ... } } - 注意不要在工厂方法里做耗时操作（如网络请求），工厂应只负责“准备”，不负责“执行”
为什么别在工厂里做初始化校验
工厂方法的职责是创建对象，不是验证输入。把配置检查、资源预分配等逻辑塞进 New()，会导致两个问题：一是无法区分“构造失败”和“使用失败”，二是难以对工厂本身做单元测试。
典型反例：func NewCache(cfg Config) Cache 里直接调用 redis.Dial()。一旦 redis 不通，整个服务启动失败，但 cache 可能根本没被用到。
- 工厂应返回可立即使用的对象，或明确返回 error（如
func() (Product, error)） - 初始化动作移到 product 的
Init()或Open()方法中，由使用者按需触发 - 若必须校验参数，应在工厂结构体的构造函数（如
NewDBFactory）里完成，而非New()方法
接口设计时如何避免工厂膨胀
当产品类型变多（如 FileLogger、HTTPLogger、CloudLogger），容易出现大量相似工厂类型，导致包层级混乱。根本解法不是增加更多工厂，而是收口构造入口。
例如统一用字符串标识类型：
func NewLogger(typ string, cfg map[string]string) (Logger, error) {
switch typ {
case "file": return NewFileLogger(cfg), nil
case "http": return NewHTTPLogger(cfg), nil
default: return nil, errors.New("unknown logger type")
}
}- 这种“简单工厂”在多数 Go 项目中比严格工厂方法更实用
- 若需插件化，用
map[string]func(map[string]string) Logger注册，比写一堆结构体干净 - 警惕过度设计：80% 场景下，一个带类型分发的函数 + 若干
NewXxx就够了
工厂方法的价值不在模式本身，而在强制你思考“谁该决定创建什么”。Go 里最容易忽略的是把工厂逻辑散落在各个 if err != nil 分支里——那不是解耦，是隐藏依赖。
