模板方法模式通过接口与组合在Go中实现算法骨架复用，定义DataProcessor接口规范LoadData与Validate步骤，Exporter结构体封装Export模板方法统一执行流程：加载→验证→格式化→输出，DBProcessor和FileProcessor分别实现不同数据源的处理逻辑，通过依赖注入灵活切换具体行为，实现流程复用与扩展解耦。
模板方法模式是一种行为设计模式，它在父类中定义算法的骨架，同时允许子类在不改变算法结构的情况下重写某些步骤。Golang虽然没有继承机制，但可以通过接口和组合的方式实现类似的效果。这种方式非常适合需要复用流程逻辑、仅修改部分步骤的场景。
定义算法骨架：使用接口与结构体
在Go中，我们通过接口定义算法中的可变步骤，再由具体结构体实现这些步骤。模板结构体持有该接口，并在“模板方法”中调用这些步骤，从而形成固定的执行流程。
以数据处理为例，假设我们要实现一个通用的数据导出流程：加载数据 → 验证数据 → 格式化 → 输出。其中加载和验证是变化的，其他步骤相对固定。
示例代码：定义步骤接口：
立即学习“go语言免费学习笔记（深入）”；
type DataProcessor interface {
LoadData() []string
Validate(data []string) bool
}
定义模板结构体和模板方法：
type Exporter struct {
processor DataProcessor
}
func (e *Exporter) Export() {
fmt.Println("开始导出...")
data := e.processor.LoadData()
if !e.processor.Validate(data) {
fmt.Println("数据验证失败，导出终止")
return
}
formatted := e.formatData(data)
e.output(formatted)
fmt.Println("导出完成")
}
func (e *Exporter) formatData(data []string) string {
return strings.Join(data, ",")
}
func (e *Exporter) output(content string) {
fmt.Printf("输出内容: %s\n", content)
}
实现具体步骤：自定义处理器
现在我们可以为不同数据源创建具体的处理器，只需实现DataProcessor接口即可。
例如：从数据库加载数据的处理器
type DBProcessor struct{}
func (dp *DBProcessor) LoadData() []string {
// 模拟从数据库读取
return []string{"user1", "user2", "admin"}
}
func (dp *DBProcessor) Validate(data []string) bool {
return len(data) > 0
}
另一个例子：从文件加载的处理器
type FileProcessor struct{}
func (fp *FileProcessor) LoadData() []string {
// 模拟读取文件
return []string{}
}
func (fp *FileProcessor) Validate(data []string) bool {
for _, item := range data {
if item == "" {
return false
}
}
return len(data) > 0
}
运行模板方法：灵活切换实现
使用时，只需将不同的处理器注入到Exporter中，调用相同的Export()方法即可。
func main() {
dbProc := &DBProcessor{}
fileProc := &FileProcessor{}
exporter := &Exporter{processor: dbProc}
exporter.Export()
exporter.processor = fileProc
exporter.Export()
}
输出结果：
开始导出... 输出内容: user1,user2,admin 导出完成 开始导出... 数据验证失败，导出终止
关键优势与适用场景
这种实现方式让算法流程集中控制，避免重复代码，同时保持扩展性。
- 算法流程统一维护，不易出错
- 新增数据源只需实现接口，无需改动模板
- 便于测试每个处理器的独立行为
- 适合报告生成、数据导入导出、构建流程等固定步骤场景
基本上就这些。Go通过组合+接口替代继承，依然能优雅实现模板方法模式的核心思想：封装不变，扩展可变。关键是把“变”与“不变”清晰分离，再通过依赖注入组装行为。不复杂但容易忽略的是，要合理划分步骤粒度，避免接口过于臃肿或过于零碎。
