17370845950

Go的模板方法应使用函数字段或接口组合实现，而非模拟Java抽象类；必填步骤需显式传入，避免隐式依赖，强调意图清晰、可替换、可验证。

模板方法的核心是定义骨架，不是写死逻辑

Go 没有继承和抽象类，所以不能照搬 Java 的 abstract class + final method 写法。强行用嵌入结构体+接口模拟，反而会让调用链变深、语义模糊。真正实用的 Go 风格模板方法，是用函数字段（func()）或接口组合来“注入”可变步骤。

用结构体字段存钩子函数，最轻量可控

把变化的部分声明为结构体的函数类型字段，在主流程中直接调用。这种方式零依赖、易测试、不隐藏控制流。

type PaymentProcessor struct {
    Validate func() error
    Charge   func() error
    Notify   func() error
}

func (p *PaymentProcessor) Execute() error {
    if p.Validate == nil {
        return fmt.Errorf("Validate not set")
    }
    if err := p.Validate(); err != nil {
        return err
    }

    if p.Charge == nil {
        return fmt.Errorf("Charge not set")
    }
    if err := p.Charge(); err != nil {
        return err
    }

    if p.Notify != nil { // 可选步骤
        _ = p.Notify()
    }
    return nil
}

• Validate 和 Charge 是强制实现步骤，Notify 是可选钩子
• 调用方完全掌控每个步骤的具体行为，无需导出子类或重写方法
• 测试时可直接传入 mock 函数，不用构造整套继承树

用接口组合替代“抽象基类”，更符合 Go 习惯

如果多个处理器共享部分逻辑（比如日志、重试），可以把公共行为抽成独立函数，再让具体类型实现差异接口。不要试图塞进一个“父接口”里。

type Payable interface {
    Validate() error
    Charge() error
}

type EmailNotifier interface {
    SendReceipt(email string) error
}

func ProcessPayment(p Payable, n EmailNotifier, email string) error {
    if err := p.Validate(); err != nil {
        return err
    }
    if err := p.Charge(); err != nil {
        return err
    }
    if n != nil {
        _ = n.SendReceipt(email)
    }
    return nil
}

• Payable 和 EmailNotifier 是正交接口，谁需要谁实现
• ProcessPayment 是普通函数，不绑定任何类型，复用性高
• 没有“模板类”的概念，只有清晰的职责切分和显式依赖

别在 init 或 New 里自动注册钩子，会破坏可预测性

常见错误是写一个 NewPaymentProcessor()，内部偷偷给 Validate 字段赋值默认函数。这会让使用者误以为流程已完备，实际却掩盖了必填项。

• 所有必填钩子必须由调用方显式传入，或 panic 提示缺失
• 避免使用全局变量或单例注册表来“自动装配”，那会引入隐式依赖和并发风险
• 如果真要简化初始化，提供带参数的构造函数（如 NewWithStripe(...)），而不是无参 New()

Go 的模板方法本质是控制反转（IoC）的一种轻量表达：你决定流程骨架，我负责填内容。关键不在“模式名字”，而在是否让每一步的意图清晰、可替换、可验证。一旦开始嵌套结构体、加标签、搞反射，就离 Go 的直觉越来越远。