golang如何实现模板方法模式_golang模板方法模式实现攻略

Go 中模板方法应使用函数字段或接口组合实现：结构体字段存函数签名，闭包捕获共享依赖，接口仅声明可变钩子，Execute 由骨架函数统一调度，并需手动管理并发安全与资源生命周期。

在 Go 语言里直接套用 Ja va 那套基于抽象类和继承的模板方法模式，往往会适得其反。生硬地模仿 abstract class 加 final func 的写法，只会让代码变得笨重，IDE 跳转困难，类型推导也容易失效。真正高效的 Go 式模板方法，核心思路其实很清晰：用结构体的函数字段或者接口的组合，把那些“固定不变的流程”封装死，同时把“可能变化的步骤”暴露成可以灵活替换的值。

用结构体字段存函数，而不是定义一堆接口

一个常见的误区是，为流程中的每个步骤都单独定义一个接口。比如，搞出个 DataLoader、Formatter、Writer，然后要求使用者必须全部实现。结果呢？想调整一点逻辑，就得动三个接口、四个方法，还特别容易忘记实现那些可选的默认行为。

更直接、更符合 Go 习惯的做法，是把这些步骤声明为结构体的字段，类型就是对应的函数签名：

type ReportGenerator struct {
    LoadData func() ([]byte, error)
    Format   func([]byte) ([]byte, error)
    Write    func([]byte) error
}
func (g *ReportGenerator) Execute() error {
    data, err := g.LoadData()
    if err != nil {
        return err
    }
    formatted, err := g.Format(data)
    if err != nil {
        return err
    }
    return g.Write(formatted)
}

使用时，只需要给关心的部分赋值即可：

立即学习“go语言免费学习笔记（深入）”；

• gen.LoadData = fetchFromDB
• gen.Format = json.Marshal
• gen.Write = writeFile

你看，这既不需要定义新的类型，也不强制实现一堆空方法。如果某个必需的函数字段忘记赋值，调用时会直接 panic，定位问题可比接口值为 nil 时的调用要明确得多。

需要共享状态？闭包比传参更干净

当多个步骤需要共用同一个数据库连接、HTTP 客户端或者配置对象时，千万别把依赖塞进每个函数的签名里。那样做只会导致签名膨胀，调用时还容易漏传。

❌ 错误示范（签名膨胀、易漏传）：

func loadFromDB(db *sql.DB, query string) ([]byte, error)
func writeToS3(s3Client *s3.Client, bucket, key string, data []byte) error

✅ 正确做法（闭包捕获依赖）：

• 先创建依赖：db := connectDB()
• 然后用闭包捕获它：gen.LoadData = func() ([]byte, error) { return loadFromDB(db, "SELECT * FROM reports") }

• 同样地：s3Client := newS3Client()
• 然后：gen.Write = func(data []byte) error { return writeToS3(s3Client, "bucket", "report.json", data) }

这样一来，函数签名保持了统一和简洁，依赖关系在闭包创建时就已经显式绑定，调用方也无需反复传递同一组参数，代码清爽了不少。

接口定义骨架时，只暴露钩子，不暴露 Execute

另一种反模式是，先定义一个包含所有步骤和执行流程的“大而全”接口。比如，一个 Processor 接口里既有 Setup()、DoWork()、Cleanup()，也包含 Execute()。问题在于，Execute() 这个固定流程的控制权，本不该交给实现者。

正确的做法是，接口只声明那些可变的“钩子”方法：

type Processor interface {
    Setup() error
    DoWork() error
    Cleanup() error
}

然后，由一个独立的骨架函数来统一调度执行顺序：

func Run(p Processor) error {
    if err := p.Setup(); err != nil {
        return err
    }
    if err := p.DoWork(); err != nil {
        return err
    }
    return p.Cleanup()
}

这样做的好处非常明显：流程的控制权始终牢牢掌握在骨架代码这一侧。使用者既无法绕过关键的 Cleanup 步骤，也不可能乱序调用。更重要的是，未来如果想为整个流程统一添加日志、超时控制或重试机制等横切关注点，只需要修改这个骨架函数即可，扩展性极佳。

并发安全与资源生命周期必须手动管理

这里有个至关重要的提醒：函数字段本身并不携带任何同步语义。如果多个 goroutine 共享同一个 ReportGenerator 实例并调用其 Execute() 方法，而其中某个步骤（例如写入同一个文件）是非线程安全的，那么数据竞争和错误就在所难免。

因此，以下两点绝不能省略：

• 并发安全：如果某个步骤涉及共享资源（比如一个缓存 map 或连接池），必须自行通过加锁或使用 sync.Pool 等机制来保证安全。
• 资源管理：如果步骤中打开了资源（如文件句柄、数据库连接），务必确保有对应的 Cleanup 逻辑被执行，或者使用 defer。函数字段不会自动绑定资源生命周期，你没写关闭逻辑，它就真的不会执行。

尤其容易被忽略的是闭包捕获的变量。例如，闭包捕获了一个 db *sql.DB，但这个连接的生命周期并不受外层结构体控制。结构体被销毁了，不代表数据库连接会自动关闭。该显式关闭的资源，一个都不能少。