在Golang的业务开发过程中，我们经常会遇到需要根据不同条件执行不同逻辑的场景，比如订单支付、优惠计算、消息推送等场景，很多开发者会直接使用大量的if else或者switch case来编写逻辑。随着业务场景不断增多，这类条件判断会变得越来越长，代码可读性和维护性都会大幅下降，而策略模式可以很好地解决这个问题。
大量if else的问题
我们先看一个典型的存在大量if else的代码示例，假设我们需要根据用户的会员等级计算订单折扣：
package main
import "fmt"
// 计算折扣的原始实现
func calculateDiscount(level string, amount float64) float64 {
if level == "normal" {
return amount * 0.95
} else if level == "vip" {
return amount * 0.9
} else if level == "svip" {
return amount * 0.85
} else if level == "diamond" {
return amount * 0.8
} else {
return amount
}
}
func main() {
fmt.Println(calculateDiscount("vip", 1000))
}
上面的代码只有4个会员等级，如果后续新增超级会员、企业会员等更多等级，就需要不断修改calculateDiscount函数，添加更多的if else分支，违反了开闭原则，而且函数会越来越臃肿，排查问题也会更困难。
策略模式的核心思想
策略模式属于行为型设计模式，它的核心思想是定义一系列算法，将每个算法封装起来，并且使它们可以相互替换，让算法的变化独立于使用算法的客户端。对应到上面的折扣计算场景，就是把每个会员等级的折扣计算逻辑封装成独立的策略，通过一个上下文对象来统一调度这些策略，避免大量的条件判断。
Golang实现策略模式的步骤
1. 定义策略接口
首先我们需要定义一个统一的策略接口，所有具体的折扣计算策略都需要实现这个接口：
// DiscountStrategy 折扣策略接口
type DiscountStrategy interface {
Calculate(amount float64) float64
}
2. 实现具体策略
接下来为每个会员等级实现对应的策略结构体，每个结构体实现Calculate方法：
// NormalDiscount 普通会员折扣策略
type NormalDiscount struct{}
func (n NormalDiscount) Calculate(amount float64) float64 {
return amount * 0.95
}
// VipDiscount VIP会员折扣策略
type VipDiscount struct{}
func (v VipDiscount) Calculate(amount float64) float64 {
return amount * 0.9
}
// SvipDiscount 超级会员折扣策略
type SvipDiscount struct{}
func (s SvipDiscount) Calculate(amount float64) float64 {
return amount * 0.85
}
// DiamondDiscount 钻石会员折扣策略
type DiamondDiscount struct{}
func (d DiamondDiscount) Calculate(amount float64) float64 {
return amount * 0.8
}
3. 实现策略上下文
上下文对象负责维护当前使用的策略，并且提供设置策略和调用策略的方法，同时可以在上下文内部维护策略的映射关系，避免外部的条件判断：
// DiscountContext 折扣策略上下文
type DiscountContext struct {
strategies map[string]DiscountStrategy
}
// NewDiscountContext 初始化上下文，注册所有策略
func NewDiscountContext() *DiscountContext {
ctx := &DiscountContext{
strategies: make(map[string]DiscountStrategy),
}
// 注册策略
ctx.strategies["normal"] = NormalDiscount{}
ctx.strategies["vip"] = VipDiscount{}
ctx.strategies["svip"] = SvipDiscount{}
ctx.strategies["diamond"] = DiamondDiscount{}
return ctx
}
// GetDiscount 根据会员等级获取对应折扣
func (ctx *DiscountContext) GetDiscount(level string, amount float64) float64 {
strategy, ok := ctx.strategies[level]
if !ok {
// 没有对应策略时返回原价
return amount
}
return strategy.Calculate(amount)
}
4. 使用策略模式重构后的调用
最后我们看重构后的调用代码，完全消除了if else判断：
func main() {
// 初始化策略上下文
ctx := NewDiscountContext()
// 计算不同会员等级的折扣
fmt.Println(ctx.GetDiscount("vip", 1000))
fmt.Println(ctx.GetDiscount("svip", 1000))
fmt.Println(ctx.GetDiscount("unknown", 1000))
}
策略模式的优势
- 符合开闭原则：新增会员等级时，只需要新增对应的策略结构体，实现
DiscountStrategy接口，然后在上下文的注册逻辑中添加新策略即可，不需要修改原有的业务逻辑代码。 - 代码可读性更强：每个策略的逻辑都封装在独立的结构体中，职责单一，排查问题时可以快速定位到对应的策略实现。
- 可维护性更高：避免了冗长的条件判断分支，修改某个等级的折扣逻辑时，只需要修改对应的策略结构体，不会影响其他策略的代码。
- 扩展性强：如果后续需要支持动态的折扣规则，比如根据活动调整折扣，只需要修改对应策略的实现，或者新增临时策略即可，不需要改动核心调用逻辑。
适用场景说明
策略模式并不是所有场景都适用，它更适合以下场景：
- 一个系统中有多种相似的算法，客户端需要根据不同条件选择其中一种算法执行。
- 一个类中有大量的条件判断语句，且这些条件判断对应不同的行为。
- 需要避免暴露复杂的、与算法相关的数据结构，只想让客户端知道算法的接口。
如果业务逻辑的条件分支很少，或者条件判断逻辑非常简单，使用策略模式反而会增加代码的复杂度，这种情况下直接使用if else是更合适的选择。