17370845950

模板方法在Go中通过函数参数或接口注入可变步骤，核心是固定流程骨架与分离变化点；函数参数适合简单场景，接口+结构体嵌入适用于多步骤、需共享状态的场景，且必须显式实现接口方法。

模板方法的核心是定义固定流程骨架

Go 没有继承和抽象类，所以不能像 Java 那样靠 abstract func() 强制子类实现。但模板方法的本质不是语法机制，而是「把不变的流程提出来，把可变的步骤留给调用方决定」。关键在于：用函数参数或接口把步骤“注入”到主流程中。

用函数类型参数实现最轻量的模板方法

适合步骤少、逻辑简单、不需复用步骤实现的场景。比如日志上报前的预处理流程：校验 → 序列化 → 发送 → 清理，其中只有序列化和发送可能变化。

• Process 函数接收 serialize 和 send 两个 func([]byte) error 类型参数，流程顺序完全固定
• 调用方传入具体实现，比如用 json.Marshal 还是 protobuf.Marshal，不影响主干逻辑
• 避免在流程里做条件判断选分支——那会破坏“固定骨架”，应让调用方自己组合函数

func Process(data interface{}, serialize func(interface{}) ([]byte, error), send func([]byte) error) error {
	if data == nil {
		return errors.New("data is nil")
	}
	b, err := serialize(data)
	if err != nil {
		return err
	}
	return send(b)
}

用接口 + 结构体嵌入模拟“抽象基类”行为

当步骤多、需要共享状态（如配置、缓存、上下文）、或步骤间有依赖时，接口更清晰。重点不是“继承”，而是让调用方实现接口，再把实例传给模板函数。

• 定义 Processor 接口，含 Validate、Transform、Persist 等方法
• 模板函数 Run 按序调用这些方法，不关心具体实现
• 结构体实现该接口时，可内嵌通用字段（如 *sql.DB 或 context.Context），避免每个方法重复传参
• 别在接口里塞太多方法——步骤膨胀后难维护，按业务边界拆成多个小接口更灵活

type Processor interface {
	Validate() error
	Transform() error
	Persist() error
}

func Run(p Processor) error {
	if err := p.Validate(); err != nil {
		return err
	}
	if err := p.Transform(); err != nil {
		return err
	}
	return p.Persist()
}

为什么不用 embed + 匿名字段自动转发？

有人尝试用嵌入一个“默认实现”结构体，再覆盖部分方法，看似接近 OOP 的模板方法。但 Go 不支持方法重写语义，匿名字段只是字段提升，不会改变调用目标——p.Transform() 调用的仍是嵌入字段的方法，而非你新定义的同名方法，除非显式重定向。

• 若结构体 A 嵌入 DefaultProcessor，又定义了 Transform() 方法，A.Transform() 是新的实现，但 A 本身仍满足 Processor 接口，因为它的方法集包含 Transform
• 真正危险的是：误以为嵌入后能“自动替换”步骤，结果运行的还是默认逻辑，调试时才发现没生效
• 接口实现必须显式提供全部方法，这是 Go 的确定性保障，别绕开它去模拟不确定的行为

模板方法在 Go 里不是语法糖，而是一种责任划分意识：谁控制流程，谁提供步骤。最容易被忽略的是步骤之间的隐式耦合——比如 Transform 依赖 Validate 设置的某个字段，但接口没声明这个契约。这种时候，文档比代码更重要。