如何使用Golang实现工厂方法与抽象工厂_Golang对象创建灵活方法

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

如何使用golang实现工厂方法与抽象工厂_golang对象创建灵活方法

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

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

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

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

  • Logger 接口统一行为,各实现(FileLoggerConsoleLogger)只管自己初始化细节
  • 不暴露 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)声明所有创建方法,但不实现
  • 每个具体工厂(WindowsFactoryMacFactory)返回对应平台的一组组件实例
  • 客户端代码只接收 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),等第三个变体出现、且它们明显属于同一维度(数据库驱动、加密算法、序列化格式),再提取公共工厂接口。

OneAI

OneAI

将生成式AI技术打包为API,整合到企业产品和服务中

下载

立即学习go语言免费学习笔记(深入)”;

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

https://www.php.cn/faq/2000129.html

发表回复

Your email address will not be published. Required fields are marked *