Golang工厂模式在解耦创建逻辑中的实践_网络技术

工厂函数应封装构造逻辑，校验参数、处理I/O错误、返回可运行实例，避免调用方依赖具体类型；NewXXX命名是Go社区惯例；需动态切换实现时才引入工厂接口；工厂须纯函数化，不读全局状态。

为什么不用 `new` 而要写工厂函数

直接调用 new 或字面量初始化结构体，会让调用方强依赖具体类型和构造细节。一旦类型内部字段变更、需要校验、或后续要替换为带连接池的实例，所有调用点都得改。工厂函数把“怎么造”收口到一处，调用方只关心“要什么”，不关心“怎么来”。

常见错误是把工厂写成简单封装：比如只做 return &MyStruct{}，没加参数校验、没处理资源初始化失败、也没预留扩展接口。这种写法看似解耦，实则只是换了个地方写 new。

必须校验必要参数（如 url 不能为空）
若涉及 I/O（如打开文件、建立 DB 连接），应在工厂内完成并返回 error
避免在工厂里写业务逻辑，只专注“创建可运行实例”这一件事

`func NewXXX(...)` 是最实用的工厂形式

Go 社区广泛接受以 New 开头的首字母大写的函数作为导出工厂，比如 NewHTTPClient、NewRepository。它轻量、无接口抽象负担，适合大多数场景。相比 Go 语言中常见的接口+结构体组合模式，这种函数工厂更直观，也更容易测试。

注意命名一致性：如果类型叫 Cache，工厂就叫 NewCache；如果类型是 redisCache（小写首字母，未导出），工厂仍应叫 NewCache 并返回导出接口或指针。

func NewCache(addr string, timeout time.Duration) (*Cache, error) {
	if addr == "" {
		return nil, errors.New("addr cannot be empty")
	}
	c := &Cache{addr: addr, timeout: timeout}
	if err := c.connect(); err != nil {
		return nil, fmt.Errorf("failed to connect: %w", err)
	}
	return c, nil
}

什么时候该上接口+工厂接口，而不是单个函数

当系统需要支持多种实现且调用方需动态切换时，比如日志后端支持 FileLogger 和 SentryLogger，且配置决定用哪一种——这时单个 NewLogger 函数就不够用了，得靠工厂接口统一创建入口。

但别过早抽象：先写死一个实现 + NewXXX 函数，等第二个实现出现、且调用方已显式依赖接口时，再提取工厂接口。否则容易陷入“为设计而设计”的陷阱。

工厂接口定义通常只需一个 Create() 方法，返回公共接口
每个实现配一个具体工厂类型，比如 FileLoggerFactory、SentryLoggerFactory
避免让工厂接口本身依赖具体实现，否则又绕回去了

工厂里别偷偷做单例或全局状态

工厂函数默认应每次返回新实例。如果内部缓存了对象（比如用 sync.Once 初始化全局 client），必须明确命名，例如 SingletonHTTPClient 或 DefaultDB，否则使用者会误以为每次调用都是独立实例，导致并发问题或测试隔离失败。

尤其要注意：测试时如果工厂返回的是共享实例，多个 test case 可能互相干扰。真正需要复用时，应由上层容器（如应用启动时）控制生命周期，而非藏在工厂里。

最容易被忽略的一点：工厂函数的参数应当完全决定输出结果。如果它读了环境变量、配置文件或全局变量，那就不是纯工厂，而是配置加载器+工厂混合体——这种耦合会极大增加单元测试难度。

# redis # go # golang # 后端 # ai # 环境变量 # 配置文件 # 为什么 # red # 封装 # Error # 全局变量 # 结构体 # 指针 # 接口 # 并发 # 对象 # 的是 # 都是 # 首字母 # 这一 # 去了 # 那就 # 多个 # 也没 # 什么时候 # 只需

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】