17370845950

不用new或字面量创建对象是为了避免强耦合，工厂方法通过返回接口解耦“谁来造”和“造什么”，适合单一产品族变化；抽象工厂则用于创建相互关联的对象族，保证风格一致。

为什么不用 new 或字面量直接创建对象？

硬编码 &MyStruct{} 或 new(MyStruct) 会让调用方和具体类型强耦合。一旦要切换实现（比如从 MySQLUserRepo 换成 PostgresUserRepo），所有创建点都得改——这不是扩展，是修补。工厂方法和抽象工厂的本质，是把“谁来造”和“造什么”解耦，让新增类型不碰旧代码。

工厂方法：用函数返回接口，隐藏具体构造逻辑

适合单一产品族、但具体类型可能变化的场景（比如日志输出目标：文件 / 控制台 / 网络）。关键不是写个叫“Factory”的结构体，而是定义一个返回接口的函数，并让不同实现各自注册或导出自己的构造函数。

• Logger 接口统一行为，各实现（FileLogger、ConsoleLogger）只管自己初始化细节
• 不暴露 FileLogger{...} 字面量，而是提供 NewFileLogger(path string) Logger
• 调用方只依赖 Logger 接口和构造函数，不 import 具体实现包（可配合接口定义放在独立 pkg/log 包）

type Logger interface {
    Log(msg string)
}

func NewFileLogger(path string) Logger {
    return &FileLogger{path: path
}
}

func NewConsoleLogger() Logger {
    return &ConsoleLogger{}
}

抽象工厂：一组相关对象的创建契约

当系统需要创建多个**相互关联**的对象（如一套 UI 组件：Button + Checkbox + Dialog），且需保证风格一致（Windows 风格 vs macOS 风格），就该用抽象工厂。Go 没有抽象类，所以用接口定义“工厂能力”，再由具体工厂实现它。

• 抽象工厂接口（GUIFactory）声明所有创建方法，但不实现
• 每个具体工厂（WindowsFactory、MacFactory）返回对应平台的一组组件实例
• 客户端代码只接收 GUIFactory 接口，完全不知道背后是 Windows 还是 Mac 实现
• 新增平台只需加新工厂结构体和实现，不改已有客户端逻辑

type Button interface{ Render() }
type Checkbox interface{ Render() }

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

type WindowsFactory struct{}
func (w WindowsFactory) CreateButton() Button { return &WindowsButton{} }
func (w WindowsFactory) CreateCheckbox() Checkbox { return &WindowsCheckbox{} }

type MacFactory struct{}
func (m MacFactory) CreateButton() Button { return &MacButton{} }
func (m MacFactory) CreateCheckbox() Checkbox { return &MacCheckbox{} }

容易踩的坑：别把工厂变*局状态或过度设计

工厂本身不该持有运行时状态（比如缓存一堆已创建对象），除非明确需要对象复用（这时应考虑 sync.Pool 而非工厂内部 map）。更常见的错误是过早抽象：只有两个实现时，硬套抽象工厂反而增加调用链和包依赖。先用简单工厂函数（func NewXxx(...) Interface），等第三个变体出现、且它们明显属于同一维度（数据库驱动、加密算法、序列化格式），再提取公共工厂接口。

接口命名别带 “Factory” 后缀（如 LoggerFactory），Go 社区习惯用功能描述（Logger）或动词（NewLogger 是函数名，不是类型）。真正难的是判断“何时抽象”——这取决于变化频率和团队对扩展点的共识，而不是模式名称本身。