Golang抽象工厂模式详解与应用技巧

本文深入解析了Go语言中抽象工厂模式的轻量级实现精髓：摒弃笨重的interface{}和类继承思维，仅凭简洁的接口定义与工厂函数即可优雅解耦产品族，实现跨平台UI组件（如Windows/macOS风格的Button与Checkbox）的一致性切换；强调产品接口应窄而稳定、工厂须无状态且不暴露具体类型，并厘清了其与简单工厂、建造者模式的职责边界——真正考验功力的不是代码能否运行，而是能否始终坚守接口契约，让业务层完全 unaware 于底层实现的变迁。

抽象工厂在 Go 里没有 interface{} 就没法玩？

不是。Go 没有类继承，但抽象工厂的核心是「封装对象创建逻辑」和「解耦产品族」，靠 interface + 工厂函数就能实现，根本不需要模拟类层级。关键在于定义清晰的产品接口，再让不同工厂返回满足同一接口但行为不同的实例。

常见错误是硬写一堆 struct{} 然后靠类型断言判断“属于哪个产品族”——这等于把工厂逻辑泄露到调用侧，违背了模式本意。

• 产品接口必须窄而稳定，比如 Button 只暴露 Render()，不暴露平台相关字段
• 每个具体工厂（如 WindowsFactory、MacOSFactory）只返回实现了该接口的本地化结构体
• 工厂本身不实现产品接口，它只是“生产者”，返回值才是实现者

怎么写一个可切换 UI 组件族的抽象工厂？

以跨平台 GUI 组件为例：需要同时支持 Windows 和 macOS 风格的 Button 和 Checkbox。抽象工厂要保证同一系统下组件风格一致，不能混用。

核心是两个层级的接口分离：UIFactory 定义创建能力，Button/Checkbox 定义使用能力。工厂返回的对象必须同时满足所有产品接口，才能组成“一族”。

type Button interface {
    Render() string
}

type Checkbox interface {
    Toggle() string
}

type UIFactory interface {
    CreateButton() Button
    CreateCheckbox() Checkbox
}

type WindowsFactory struct{}

func (w WindowsFactory) CreateButton() Button {
    return &WindowsButton{}
}

func (w WindowsFactory) CreateCheckbox() Checkbox {
    return &WindowsCheckbox{}
}

type WindowsButton struct{}

func (b *WindowsButton) Render() string {
    return "Rendering a Windows-style button"
}

type WindowsCheckbox struct{}

func (c *WindowsCheckbox) Toggle() string {
    return "Toggling Windows checkbox"
}

为什么不用 new(WindowsButton) 直接构造？

直接调用 new(WindowsButton) 或字面量初始化会把具体类型暴露给业务代码，导致后续想切到 macOS 风格时，得全局搜索替换所有 WindowsButton —— 这就是抽象工厂要解决的问题：让上层只依赖接口，不感知实现。

另一个常被忽略的点是：工厂函数应尽量无状态。如果工厂内部缓存了配置或连接池，容易引发并发问题或测试困难。推荐把差异化参数（如 theme、locale）作为工厂构造参数传入，而不是在 CreateXXX() 方法里动态判断：

• ❌ 错误：在 CreateButton() 里读环境变量决定返回哪种按钮
• ✅ 正确：用 NewMacOSFactory(theme string) 构造工厂，内部保存 theme，各 Create 方法复用它

抽象工厂和简单工厂、建造者混用时要注意什么？

抽象工厂管的是「产品族」，简单工厂管的是「单个产品类型」，建造者管的是「复杂对象的逐步构建」。三者可以共存，但边界必须清晰。

例如：用抽象工厂返回一个 Dialog 接口，而这个 Dialog 内部可能用建造者模式组装多个 Button 和 Label —— 此时工厂不关心 Dialog 怎么建，只负责提供符合当前平台契约的 Dialog 实例。

最容易踩的坑是让抽象工厂承担太多职责：比如在 CreateDialog() 里又去调用 buttonBuilder.SetSize().SetColor()。这会让工厂变得臃肿且难以测试。应该把构建逻辑下沉，工厂只做“选择并组合”。

真正难的不是写出来，而是守住接口边界：一旦某个 CreateXXX() 开始返回具体类型（比如返回 *sql.DB 而不是 DBClient 接口），整个抽象就塌了一半。

终于介绍完啦！小伙伴们，这篇关于《Golang抽象工厂模式详解与应用技巧》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！