Golang工厂模式应用实例解析

Go中的工厂模式核心在于优雅地收口对象创建逻辑、统一注入配置参数并隐藏具体实现细节，它不是可选项而是必选项——当代码中频繁出现硬编码初始化、多处重复new结构体、或需要根据配置动态选择类型时，工厂就能帮你避免散乱的创建逻辑、提升扩展性与可测试性；通过返回接口而非具体结构体、用注册表替代冗长switch、确保工厂函数轻量且职责单一，你不仅能轻松应对新增支付方式或日志后端，还能让单元测试更简单、配置变更更安全，真正把“怎么创建”和“怎么使用”彻底解耦。

Go 里工厂模式不是“要不要用”，而是“怎么用才不踩坑”——它最适合解决对象创建逻辑分散、初始化参数多、或需隐藏具体类型实现的场景。

什么时候该写 NewLogger 而不是直接 &FileLogger{}

当你发现代码里反复出现类似 &FileLogger{filePath: "/tmp/app.log", level: "debug"} 这种硬编码初始化，或者不同包里各自 new 同一个结构体时，就该上工厂了。工厂把初始化逻辑收口，后续加校验、打日志、做连接池预热都方便。

• 配置来自环境变量或 YAML 文件 → 工厂函数可统一解析并注入
• 结构体字段必须非空（比如数据库 connString）→ 工厂里做 panic 或 error 返回，避免运行时 panic
• 想让结构体对外不可直接实例化 → 把结构体首字母小写（如 fileLogger），只暴露 NewFileLogger 函数

NewPayment 为什么常返回接口而不是结构体

因为调用方真正需要的不是 *Alipay，而是能 Pay(amount float64) 的能力。返回 Payment 接口，才能做到：新增 UnionPay 时不改任何业务代码；单元测试时轻松 mock；HTTP handler 里传入任意支付方式而不耦合实现。

• 如果返回具体结构体（如 *Alipay），调用方就和实现强绑定了，扩展性归零
• 接口定义要窄：只包含调用方真正在用的方法，别把 Cancel() Refund() 全塞进去
• 注意值接收 vs 指针接收：若结构体含状态（如缓冲区、连接池），必须用指针方法实现接口，否则每次调用都是副本

大量 switch 分支难维护？试试注册表 + map[string]func()

当 NewLogger 里 case 超过 5 个，或者类型要从配置文件动态加载时，硬写 switch 就成了技术债。用 map 注册工厂函数更灵活，也方便单元测试替换。

var loggerFactories = map[string]func(string) Logger{
    "console": func(_ string) Logger { return &ConsoleLogger{} },
    "file":    func(path string) Logger { return &FileLogger{FilePath: path} },
    "http":    func(addr string) Logger { return &HttpLogger{Endpoint: addr} },
}

func NewLogger(typ, config string) (Logger, error) {
    factory, ok := loggerFactories[typ]
    if !ok {
        return nil, fmt.Errorf("unknown logger type: %s", typ)
    }
    return factory(config), nil
}

• 注册表可放在 init() 函数里，或由主程序启动时显式调用
• map key 建议全小写，避免大小写敏感问题（尤其配置来自 JSON/YAML）
• 别在 map value 里做耗时操作（如打开文件、建 HTTP 连接），工厂函数应轻量，构建后立刻返回

最常被忽略的一点：工厂函数本身不该承担“运行时决策”以外的责任。比如日志级别过滤、消息序列化这些，应该交给 Logger 实现内部处理，而不是在工厂里根据参数拼出不同结构体变体——那会把简单工厂演变成反模式的“配置爆炸”。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。