Golang模板方法模式：算法骨架与子类实现

在Go语言中，模板方法模式并非通过继承实现，而是巧妙运用组合、接口和函数字段来定义算法骨架与具体行为的分离——骨架逻辑被提炼为独立的包级函数，仅依赖最小接口（如Processor），而各类实现则各自满足该接口，完全解耦；这种设计不仅规避了Go无继承和抽象方法的限制，还提升了可测试性（通过轻量匿名结构体mock接口行为）和可维护性（避免嵌入导致的方法调用陷阱），真正践行了Go“组合优于继承”的核心哲学。

Go 里没有继承，怎么写模板方法模式

直接说结论：用组合 + 接口 + 函数字段，比继承更清晰，也更符合 Go 的设计哲学。硬套类继承式模板方法（比如想定义 abstract method）会卡在编译器报错，因为 Go 没有 abstract 关键字，也没有子类 override 机制。

典型错误现象是试图写一个带未实现方法的 struct，然后让另一个 struct “继承”它——go build 直接失败，提示 undefined 或 cannot use … as … value。

• 把“算法骨架”抽成普通函数，接收一个接口类型参数（比如 Processor），该接口声明子类需提供的行为（如 Setup()、Execute()、Teardown()）
• 具体实现不嵌入父 struct，而是单独实现接口；骨架函数只调用接口方法，不关心谁实现
• 如果需要共享状态或预设逻辑，用字段注入（比如把 *log.Logger 或配置结构体作为字段传入实现类），而不是靠“父类字段”隐式继承

templateMethod 函数怎么设计才不耦合

关键不是“怎么定义骨架”，而是“怎么让骨架不依赖具体实现”。常见错误是把 templateMethod 写死在某个 struct 里，又让它调用自己未导出的方法，结果外部无法替换行为。

正确做法是把骨架逻辑完全独立出来，作为包级函数，只依赖最小接口：

func RunPipeline(p Processor) error {
    if err := p.Setup(); err != nil {
        return err
    }
    if err := p.Execute(); err != nil {
        return err
    }
    return p.Teardown()
}

这里 Processor 是接口，RunPipeline 不知道也不需要知道 p 是 *HTTPHandler 还是 *FileImporter。

• 避免在骨架函数里 new 具体类型（比如 &HTTPHandler{…}），那会让调用方失去控制权
• 如果骨架需要可选步骤（比如某些流程跳过 Teardown），用函数字段替代接口方法：接口加 ShouldTeardown() bool，比强行实现空方法更明确
• 参数尽量用值或接口，别传指针到内部状态——否则不同实现可能意外共享数据

为什么不用 embed 匿名字段模拟继承容易翻车

有人试过在子 struct 里 embed 一个“基类” struct，再覆盖其方法。Go 不支持方法覆盖，嵌入只是委托调用，Base.Do() 调用的永远是 Base 自己的方法，不会自动转向子 struct 的同名方法。

典型错误代码：

type Base struct{}
func (b *Base) Template() { b.step1(); b.step2() }
func (b *Base) step1() { fmt.Println("base step1") }
func (b *Base) step2() { fmt.Println("base step2") }

type Child struct {
    Base // ← 这里 embed 不会重定向 step2 调用
}
func (c *Child) step2() { fmt.Println("child step2") } // ← 这个方法永远不会被 Template() 调到

• 嵌入后 c.Template() 输出仍是两行 “base”，因为 Template 方法体内调用的是 b.step2()，不是 c.step2()
• 如果硬要靠嵌入+重命名绕开（比如 base Base + 显式调用 c.base.step1()），代码立刻变脆：每个子类都要手动重写所有骨架调用点
• 真正需要复用逻辑时，用私有 helper 函数（如 defaultSetup()）更安全，调用方按需组合，不靠语言特性“假装继承”

测试 templateMethod 时 mock 哪些东西最实际

测试重点不是“骨架函数有没有跑”，而是“它是否按顺序、按条件调用了预期的接口方法”。最容易忽略的是错误传播路径和边界条件。

比如 RunPipeline 在 Setup() 失败时不该调 Execute()，但很多人只测 happy path。

• mock 实现必须能控制每个方法的返回值（尤其是 error），用匿名结构体比完整 struct 更轻量：Processor = &mockProc{setupErr: io.EOF}
• 别 mock 日志或 HTTP 客户端——那些是实现细节；要 mock 的是接口方法本身的行为契约
• 如果骨架里有 sleep 或 retry，测试时用 time.AfterFunc 或注入 clock Clock 接口，避免真实等待

复杂点在于：当多个实现共用同一骨架，但各自对 Execute() 的幂等性、并发安全要求不同时，骨架函数本身无法替你保证——那得靠每个实现自己处理，别指望“父类”兜底。

今天关于《Golang模板方法模式：算法骨架与子类实现》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！