Golang简单工厂与抽象工厂的实现差异

简单工厂是用单个函数根据参数创建不同具体类型对象的封装手段，如NewLogger(type string) Logger；抽象工厂则是GoF模式，通过定义工厂接口及其实现来创建一族相关对象，如DBFactory接口及MySQLFactory实现。

简单工厂用一个函数创建多种类型实例

简单工厂不是 GoF 23 种设计模式之一，而是常见封装手段：用单个函数（通常是 NewXXX 或 Create）根据参数返回不同具体类型的对象。它不强调接口抽象，重点是“隐藏构造细节”。

典型场景：解析不同格式的配置文件、创建不同数据库驱动连接、生成不同日志输出器。

• 所有具体类型需实现同一接口（如 Logger），但工厂本身不依赖该接口的多态扩展
• 新增类型需修改工厂函数逻辑，违反开闭原则
• 没有“工厂类”，通常就是一个包级函数，例如 log.NewLogger(type string) Logger
• 无法应对“一族相关对象”的创建需求（比如 MySQL 连接 + MySQL 事务 + MySQL 语句预编译器）

func NewLogger(typ string) Logger {
    switch typ {
    case "file":
        return &FileLogger{}
    case "console":
        return &ConsoleLogger{}
    default:
        return &NullLogger{}
    }
}

抽象工厂必须定义工厂接口并为每族产品提供实现

抽象工厂是 GoF 模式，核心是定义一个创建一族相关或相互依赖对象的接口（Factory），再为每种产品族提供具体工厂实现（如 MySQLFactory、PostgresFactory）。它解决的是“多系列平行类簇”的创建问题。

典型场景：跨数据库适配（连接、事务、语句）、UI 组件库适配（按钮、输入框、下拉框的不同风格实现）。

• 必须先定义产品接口族（如 Connection、Transaction、Statement）和工厂接口（DBFactory）
• 每个具体工厂（MySQLFactory）实现工厂接口，返回对应系列的具体类型
• 客户端只依赖工厂接口和产品接口，完全解耦具体实现
• 新增产品族只需添加新工厂实现，不改现有代码；但新增产品类型（如加一个 Migration）需修改所有工厂接口和实现，代价大

type DBFactory interface {
    CreateConnection() Connection
    CreateTransaction() Transaction
}

type MySQLFactory struct{}

func (m MySQLFactory) CreateConnection() Connection {
    return &MySQLConnection{}
}

func (m MySQLFactory) CreateTransaction() Transaction {
    return &MySQLTransaction{}
}

Go 中抽象工厂常被接口组合+依赖注入替代

Go 没有类继承，也不鼓励复杂工厂层级。多数真实项目中，抽象工厂的“一族对象”往往通过结构体字段组合接口来表达，工厂逻辑则退化为构造函数或 DI 容器注册。

• MySQLClient 结构体直接持有 Connection、Transaction 等接口字段，由调用方传入（显式依赖）
• 使用 Wire / Dig 等 DI 工具时，“工厂”变成 provider 函数，按需绑定一组接口到具体实现
• 若硬要模拟抽象工厂，Go 的 interface{} 或泛型（Go 1.18+）可减少重复，但会牺牲类型安全或增加泛型约束复杂度
• 简单工厂在 Go 中更自然——因为 Go 偏好小接口、短函数、显式构造，NewXXX() 就是事实标准

错误理解：把 newXXX() 当成抽象工厂

常见误区是认为 json.NewDecoder(r io.Reader) 或 http.NewServeMux() 是抽象工厂——它们只是带参数的构造函数，返回单一类型，不涉及“一族对象”或“可替换实现族”。

• 抽象工厂的关键标志是：存在多个并列的产品接口 + 一个能同时创建它们的工厂接口
• 如果只有一个返回类型，哪怕参数是 string 或 int，也只是简单工厂（甚至不算模式，只是封装）
• Go 标准库几乎不用抽象工厂；database/sql 的驱动注册机制接近，但靠的是全局 map + sql.Open() 查表，不是接口实现族

抽象工厂在 Go 中真正落地时，最容易被忽略的是“一族对象的生命周期一致性”——比如 Transaction 必须来自同一个 Connection，这需要工厂保证内部状态关联，而不仅仅是返回独立实例。