在软件开发中，我们经常遇到需要根据不同条件执行不同算法的场景。传统的if-else或switch-case虽然直观，但随着业务复杂度增长会变得难以维护。这时，策略模式（Strategy Pattern）便显现出它的价值。

一、策略模式的核心思想

策略模式属于行为型设计模式，其核心是将算法家族分别封装，使它们可以互相替换。这种模式让算法的变化独立于使用算法的客户端。

在Go语言中，我们通过接口+结构体的组合来实现这一模式。与Java等语言不同，Go没有传统的类继承体系，但通过接口的隐式实现，反而让策略模式更加轻量灵活。

go
type Strategy interface {
Execute(context string) (result string, err error)
}

type FastStrategy struct{}

func (s *FastStrategy) Execute(context string) (string, error) {
return "快速执行结果", nil
}

type PreciseStrategy struct{}

func (s *PreciseStrategy) Execute(context string) (string, error) {
return "精准执行结果", nil
}

二、实战：电商促销策略系统

假设我们需要实现一个电商促销系统，根据不同的营销场景（双11、618、日常促销）应用不同的折扣策略。传统实现可能会这样写：

go func CalculateDiscount(style string, price float64) float64 { switch style { case "double11": return price * 0.5 case "618": return price * 0.7 default: return price * 0.9 } }

这种硬编码方式存在明显问题：每次新增策略都需要修改核心逻辑、难以单独测试某类策略、业务规则混在流程控制中。

让我们用策略模式重构：

go
type DiscountStrategy interface {
Calculate(price float64) float64
}

type Double11Strategy struct{}
func (s *Double11Strategy) Calculate(price float64) float64 {
return price * 0.5
}

type NormalStrategy struct{}
func (s *NormalStrategy) Calculate(price float64) float64 {
return price * 0.9
}

type StrategyContext struct {
strategy DiscountStrategy
}

func (ctx *StrategyContext) SetStrategy(s DiscountStrategy) {
ctx.strategy = s
}

func (ctx *StrategyContext) Calculate(price float64) float64 {
return ctx.strategy.Calculate(price)
}

客户端调用时：

go
func main() {
ctx := &StrategyContext{}

// 双11策略
ctx.SetStrategy(&Double11Strategy{})
fmt.Println(ctx.Calculate(100)) // 输出50

// 日常策略
ctx.SetStrategy(&NormalStrategy{})
fmt.Println(ctx.Calculate(100)) // 输出90

}

三、高级技巧：策略工厂模式

在实际工程中，我们通常需要将策略的创建逻辑集中管理。这时可以结合工厂模式：

go
type StrategyType int
const (
StrategyNormal StrategyType = iota
StrategyDouble11
Strategy618
)

func NewStrategy(t StrategyType) DiscountStrategy {
switch t {
case StrategyDouble11:
return &Double11Strategy{}
case Strategy618:
return &618Strategy{}
default:
return &NormalStrategy{}
}
}

// 使用示例
strategy := NewStrategy(StrategyDouble11)
ctx.SetStrategy(strategy)

四、性能优化考虑

1. 策略对象复用：无状态的策略对象可以设计为单例
2. 避免反射：类型判断优先使用接口而非reflect包
3. 内存分配：对于简单策略，考虑使用函数式实现

go
type DiscountFunc func(float64) float64

func (f DiscountFunc) Calculate(price float64) float64 {
return f(price)
}

// 注册策略
strategies := map[string]DiscountStrategy{
"double11": DiscountFunc(func(p float64) float64 { return p0.5 }), "normal": DiscountFunc(func(p float64) float64 { return p0.9 }),
}

五、测试策略模式

策略模式的一个显著优势是便于单元测试。我们可以针对每个策略单独测试：

go func TestDouble11Strategy(t *testing.T) { s := &Double11Strategy{} if s.Calculate(100) != 50 { t.Error("折扣计算错误") } }

还可以使用表格驱动测试验证多个策略：

go
func TestStrategies(t *testing.T) {
cases := []struct{
name string
strategy DiscountStrategy
input float64
expect float64
}{
{"双11", &Double11Strategy{}, 200, 100},
{"日常", &NormalStrategy{}, 200, 180},
}

for _, c := range cases {
    t.Run(c.name, func(t *testing.T) {
        if actual := c.strategy.Calculate(c.input); actual != c.expect {
            t.Errorf("预期 %.2f 实际得到 %.2f", c.expect, actual)
        }
    })
}

}

六、与其他模式的协作

策略模式常与其他模式结合使用：

1. 与模板方法模式结合：定义算法骨架，策略实现具体步骤
2. 与装饰器模式结合：动态添加策略功能
3. 与责任链模式结合：形成策略处理链

go
// 策略链示例
type ChainStrategy struct {
strategies []DiscountStrategy
}

func (c *ChainStrategy) AddStrategy(s DiscountStrategy) {
c.strategies = append(c.strategies, s)
}

func (c *ChainStrategy) Calculate(price float64) float64 {
for _, s := range c.strategies {
price = s.Calculate(price)
}
return price
}

七、工程实践建议

1. 接口设计原则：保持策略接口足够精简（通常3-5个方法）
2. 文档规范：为每个策略编写清晰的文档注释
3. 错误处理：定义统一的错误类型
4. 版本兼容：考虑策略的版本迭代方案

go
// 定义策略错误类型
type StrategyError struct {
Code int
Message string
}

func (e *StrategyError) Error() string {
return fmt.Sprintf("策略错误[%d]: %s", e.Code, e.Message)
}

// 在接口中明确错误
type AdvancedStrategy interface {
Execute(input interface{}) (output interface{}, err *StrategyError)
}

结语

通过Golang的接口和多态实现的策略模式，我们获得了以下优势：

1. 开闭原则：新增策略无需修改现有代码
2. 可测试性：每个策略可以独立测试
3. 解耦：业务逻辑与具体实现分离
4. 可扩展性：轻松支持新策略类型

在实际项目中，策略模式特别适用于以下场景：
- 需要动态切换算法
- 有多个相似条件的分支判断
- 需要隔离复杂的业务规则
- 算法需要频繁变更或扩展

记住，设计模式不是银弹。当策略数量较少（如3个以下）或很少变化时，简单的条件判断可能更合适。工程师应该根据实际场景灵活选择解决方案。

"模式的智慧不在于形式，而在于对变化的封装。" —— Go语言实践者