Golang简单工厂模式：接口与实例解耦实现

本文深入探讨了在Golang中正确实现简单工厂模式的关键实践：强调工厂函数（如`NewPrinter`）必须返回接口而非具体类型，以彻底解耦调用方与实现细节；主张工厂与接口定义同包、实现包仅依赖接口包，杜绝隐式导入和脆弱类型断言；推荐用自定义类型（如`PrinterType`常量）替代易错的字符串参数，提升类型安全与IDE友好性；同时指出接口方法设计需聚焦单一能力，参数由调用方控制，避免将配置、生命周期等职责混入本该轻量的“创建”逻辑——让工厂真正回归本质：干净、稳定、可扩展的对象创建枢纽。

为什么 NewPrinter 不该返回具体类型

工厂函数如果直接返回 *PdfPrinter 或 *TextPrinter，调用方就不得不 import 具体实现包，还可能写 if p, ok := printer.(*PdfPrinter) 这种脆弱判断。接口抽象失效，后续加 *HtmlPrinter 就得改所有调用点。

正确做法是让工厂只暴露接口，隐藏实现：

type Printer interface {
	Print(string) error
}

func NewPrinter(kind string) Printer {
	switch kind {
	case "pdf":
		return &PdfPrinter{} // 返回指针，但类型是 Printer
	case "text":
		return &TextPrinter{}
	default:
		return &TextPrinter{}
	}
}

• NewPrinter 的返回类型必须是 Printer 接口，不是任何结构体指针
• 各实现类型（如 PdfPrinter）要显式实现 Print 方法，否则编译报错：cannot use &PdfPrinter{} as Printer
• 别在工厂里 new 后再强转——return (*PdfPrinter)(nil) 是错的，Go 不支持运行时类型转换

如何避免工厂逻辑散落在多个文件里

常见错误是把 NewPrinter 放在 main.go，而 PdfPrinter 定义在 pdf/print.go，导致 main 包依赖所有实现包，破坏解耦。

把工厂和接口定义收拢到一个包里，实现包只依赖接口包：

// printer/printer.go
package printer

type Printer interface { ... }
func NewPrinter(kind string) Printer { ... }

// pdf/pdf.go
package pdf

import "yourapp/printer"

type PdfPrinter struct{}
func (p *PdfPrinter) Print(s string) error { ... }
// 注意：这里不 import main，也不 export NewPdfPrinter

• 实现包（如 pdf）不能导出构造函数，只暴露满足 Printer 的类型
• 工厂函数 NewPrinter 必须和 Printer 接口在同一个包，否则调用方仍需 import 实现包来断言类型
• 如果实现类型带依赖（如 *http.Client），工厂函数应接受参数，而不是在内部 new —— 否则无法测试或替换依赖

字符串参数 kind 为什么容易出错

用字符串做类型分发，拼错、大小写不一致、多空格都会导致默认分支或 panic。比如传 "PDF" 却只匹配 "pdf"，结果默默用 TextPrinter 打印 PDF 内容，问题延迟暴露。

更安全的方式是用自定义类型约束输入：

type PrinterType string
const (
	PdfPrinterType  PrinterType = "pdf"
	TextPrinterType PrinterType = "text"
)

func NewPrinter(kind PrinterType) Printer {
	switch kind {
	case PdfPrinterType:
		return &PdfPrinter{}
	case TextPrinterType:
		return &TextPrinter{}
	default:
		panic("unknown printer type: " + string(kind))
	}
}

• 调用方只能用预定义常量：printer.NewPrinter(printer.PdfPrinterType)，IDE 能自动补全，拼写错误编译即报
• 保留字符串 fallback 的场景（如配置文件读取）可加一层转换函数，但工厂内部仍用类型匹配
• 别为了“灵活”在 switch 里写正则或 substring 判断——简单工厂本就不处理动态扩展，那是抽象工厂或插件系统的职责

接口方法设计不当会拖垮整个工厂

如果 Printer.Print 方法签名是 Print(*bytes.Buffer, string) error，那 PdfPrinter 就得自己处理 buffer 生命周期；如果改成 Print(io.Writer, string) error，又会让 TextPrinter 多一层 os.Stdout 传参，调用变重。

核心原则：接口方法参数应由调用方控制，而非被工厂绑定：

• 避免接收指针或结构体作为参数（如 *Config），否则每个实现都要解析同一份配置，违背解耦初衷
• 优先用 Go 标准库接口（如 io.Writer）作为参数，但注意：如果所有实现都只写文件，那就该让工厂返回 io.Writer，而不是另造 Printer 接口
• 方法名别用 CreateBuildGenerate——这些词暗示副作用或状态变更；PrintSendSave 更贴近真实行为

工厂模式的边界很窄：它只解决“根据输入创建某类对象”的问题。一旦开始在接口里塞 Configure、Validate、Close，就说明这个接口已经不是“能力契约”，而是“生命周期契约”了——这时候该考虑组合或拆分接口，而不是硬塞进工厂。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。