如何在Golang中实现策略模式_Golang策略设计模式应用与实例

策略接口是定义行为契约的窄接口（如DiscountStrategy），必须用具体接口而非Interface{}以保证编译期类型安全和可替换性。

什么是策略接口，为什么必须用 interface{}？

go 没有传统面向对象的抽象类或虚函数，策略模式依赖的是接口契约。定义策略的核心是声明一个 Strategy 接口，它只包含行为方法（比如 Execute()），不关心实现细节。

常见错误是试图用结构体字段存具体类型，或者把策略硬编码成 *ConcreteStrategyA 这样的指针——这会破坏可替换性。正确做法是让所有策略实现同一接口，调用方只持有该接口变量。

• 接口定义要窄：只暴露策略必须提供的能力，例如 CalculateDiscount(price float64) float64
• 避免在接口里塞无关方法（如日志、初始化），否则违反单一职责
• 不要用 interface{}（空接口）代替策略接口——它失去类型约束，编译期无法检查是否实现了所需方法

如何动态切换策略而不改主逻辑？

关键在于把策略作为参数注入，而不是在业务代码里 if-else 判断后 new 一个具体类型。典型场景是支付方式选择、折扣计算、序列化格式切换等。

示例：一个订单服务支持多种折扣策略：

立即学习“go语言免费学习笔记（深入）”；

type DiscountStrategy interface {     apply(amount float64) float64 } 
type FlatRateStrategy struct{ rate float64 } func (s FlatRateStrategy) Apply(amount float64) float64 { return amount * s.rate }
type ThresholdStrategy struct{ min, discount float64 } func (s ThresholdStrategy) Apply(amount float64) float64 { if amount >= s.min { return amount - s.discount } return amount }
// 主逻辑不感知具体策略 func ProcessOrder(total float64, strategy DiscountStrategy) float64 { return strategy.Apply(total) }

• 新增策略只需实现 DiscountStrategy，无需修改 ProcessOrder
• 策略实例可从配置、http 头、数据库读取后构造，再传入
• 注意值接收 vs 指针接收：若策略含状态（如计数器），需用指针实现；纯函数式策略用值接收更安全

策略注册表怎么避免全局变量污染？

当策略种类多、来源分散（比如插件式加载），直接在 init() 里注册到全局 map 容易引发初始化顺序问题和测试困难。

推荐用依赖注入容器或显式注册函数，由启动逻辑统一管理：

var strategies = make(map[string]DiscountStrategy) 
func RegisterStrategy(name string, s DiscountStrategy) { strategies[name] = s }
func GetStrategy(name string) (DiscountStrategy, bool) { s, ok := strategies[name] return s, ok }

• 注册应发生在 main() 或应用初始化阶段，而非包级变量初始化
• 测试时可清空 strategies map 或传入 mock 策略，避免跨测试污染
• 若策略需初始化（如连接 DB），不要在 RegisterStrategy 里做重操作，而是延迟到首次 Apply() 时懒加载

为什么策略不能带 context.Context？

策略方法签名里混入 context.Context 是常见反模式。它会让简单计算逻辑被迫处理超时、取消等控制流，违背“策略只负责算法”的原则。

真正需要上下文的场景（如远程调用型策略），应该把 context 交给策略的执行环境，而不是塞进策略接口本身：

• 策略接口保持无副作用、无 IO、无 context —— 这样才能被安全缓存、并发复用
• 如果某策略内部要发 HTTP 请求，应封装为 RemoteDiscountStrategy，并在其 Apply() 内部自行处理 context（比如用 ctx, cancel := context.WithTimeout(...)）
• 主流程如 ProcessOrder 若需整体超时，应在调用前控制，而不是让每个策略自己解析 context

策略模式的干净边界容易被“顺便加个日志”“顺手传个 config”这类需求悄悄腐蚀，越早明确它的职责边界，后期维护成本越低。