直接 new struct 不适合多变创建逻辑,因硬编码会导致 if/else 泛滥且新增类型需修改入口;工厂模式将实例化决策剥离,函数型工厂返回接口实现解耦,结构体工厂支持配置与依赖注入,但需注意指针接收者匹配及错误处理。

为什么 直接 new struct 不适合多变的创建逻辑
当业务中需要根据参数动态决定创建哪种具体类型(比如不同支付方式:Alipay、WechatPay、BankTransfer),硬 编码 &Payment{Type: "alipay"} 会快速导致 if/else 泛滥,且每新增一种类型都要改创建入口。工厂模式把“实例化谁”这个决策从调用方剥离,交给专门的工厂函数或结构体处理。
用函数型工厂实现最简解耦
Go 没有类继承,但函数是一等公民,用返回接口的工厂函数足够轻量。关键点在于:工厂不暴露具体类型,只返回统一接口;调用方完全不知道底层是哪个 struct。
type Payment interface {Process(amount float64) error } type Alipay struct{} func (a *Alipay) Process(amount float64) error {// 实现 return nil} type WechatPay struct{} func (w *WechatPay) Process(amount float64) error {// 实现 return nil} // 工厂函数:输入类型名,输出 Payment 接口 func NewPayment(kind string) Payment {switch kind { case "alipay": return &Alipay{} case "wechat": return &WechatPay{} default: return nil // 或 panic,视错误策略而定} }
- 调用方只需
NewPayment("alipay"),无需 import 具体实现包 - 新增支付方式时,只改工厂函数内部 switch,不碰已有调用代码
- 注意:返回
nil可能引发 panic,建议配合error返回或使用指针 +ok 模式
用结构体工厂支持配置化与依赖注入
当创建对象需要传入配置(如 API key、超时时间)或依赖其他服务(如日志器、数据库连接),函数型工厂不够灵活。此时定义一个带字段的工厂结构体更清晰。
type PaymentFactory struct {Logger *zap.Logger Timeout time.Duration} func (f *PaymentFactory) New(kind string, config map[string]string) (Payment, error) {switch kind { case "alipay": return &Alipay{ Key: config["key"], Logger: f.Logger, Timeout: f.Timeout, }, nil case "wechat": return &WechatPay{AppID: config["appid"], Logger: f.Logger, Timeout: f.Timeout, }, nil default: return nil, fmt.Errorf("unknown payment kind: %s", kind) } }
- 工厂自身可携带共享依赖(
Logger、Timeout),避免每个创建都重复传参 -
config map[string]string提供扩展性,不同子类型按需解析自己关心的字段 - 返回
error而非nil,让调用方必须显式处理创建失败场景
工厂方法和接口组合容易被忽略的坑
Go 的接口是隐式实现,但工厂返回接口时,若忘记加 *(即返回值类型是 Alipay 而非 *Alipay),会导致方法集不匹配——因为只有指针才拥有接收者为指针的方法。
立即学习“go 语言免费学习笔记(深入)”;
- 检查你的 struct 方法接收者:如果
Process是func (p *Alipay) Process(……),那工厂必须返回&Alipay{},不能是Alipay{} - 工厂函数签名别写成
func() *Payment—— 接口不能取地址,*Payment是非法类型 - 测试工厂时,别只测能否创建,要验证返回对象是否真能调用接口方法(尤其涉及嵌入字段或组合时)
工厂不是银弹。当类型分支极少(仅 2–3 种)、生命周期极短、或创建逻辑本身无状态时,直接 new 更直白。真正需要工厂的,是那些创建成本高、依赖复杂、或未来大概率要横向扩展的组件。