Golang模板方法封装业务逻辑详解

模板方法模式通过定义算法骨架并延迟具体步骤到子类，在Go中利用接口与组合实现，适用于订单处理等流程固定但步骤差异的场景，提升代码复用性与扩展性。

在Go语言开发中，模板方法模式能有效解决多个业务流程结构相似、仅部分步骤不同的问题。通过该模式，可以把共用的流程骨架抽象出来，将可变的部分延迟到子类实现，从而实现业务逻辑的统一封装与灵活扩展。

模板方法模式的核心思想

定义一个算法的执行步骤，并将其中某些步骤的具体实现延迟到子类中。父类（通常是接口或结构体）控制整体流程顺序，子类只负责实现特定环节，不改变整体结构。

在Golang中，由于没有继承机制，我们通常使用组合+接口的方式来模拟这一行为。

典型场景：订单处理流程

假设不同类型的订单（如普通订单、团购订单、秒杀订单）都需要经历“校验 → 锁定库存 → 扣款 → 发货”等流程，但每个环节的具体实现略有不同。

我们可以这样设计：

先定义每一步操作的行为接口：

type OrderProcessor interface {
  Validate() error
  LockStock() error
  DeductPayment() error
  Ship() error
}

创建一个通用处理器，按固定顺序调用这些方法：

type TemplateOrderService struct {
  processor OrderProcessor
}

func (s *TemplateOrderService) Process() error {
  if err := s.processor.Validate(); err != nil {
    return err
  }

  if err := s.processor.LockStock(); err != nil {
    return err
  }

  if err := s.processor.DeductPayment(); err != nil {
    return err
  }

  return s.processor.Ship()
}

针对不同订单，实现各自的处理逻辑：

type NormalOrder struct{}
func (o *NormalOrder) Validate() error { ... }
func (o *NormalOrder) LockStock() error { ... }
// 其他方法实现

type GroupBuyOrder struct{}
func (o *GroupBuyOrder) Validate() error { ... } // 额外验证成团人数
func (o *GroupBuyOrder) LockStock() error { ... } // 特殊库存策略
// 其他方法实现

使用时只需注入对应的实现：

service := &TemplateOrderService{processor: &NormalOrder{}}
err := service.Process()

优势与注意事项

这种封装方式带来几个明显好处：

• 统一核心流程，避免重复代码
• 增强可维护性，修改流程只需调整模板
• 扩展性强，新增订单类型无需改动主逻辑
• 便于测试，可对各步骤单独 mock

需要注意的是，Golang中应避免过度设计。如果差异点很少，直接使用函数参数或配置可能更简洁。只有当流程结构稳定且存在多套变体时，才推荐使用模板方法模式。

基本上就这些，关键在于把变与不变分离，让代码更清晰。