如何在Golang中实现模板方法模式_Golang模板方法模式流程控制示例

P粉602998670 2026-01-03 00:00:00 次阅读

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
}