# 概述
我们写代码时，是不是经常遇到一个场景：一个任务，有多种不同的完成方式？比如，给用户数据排序，有时按时间，有时按金额；计算运费，有时按重量，有时按体积；或者像文档里提到的，规划路线，可以开车、步行、坐公交。

**策略模式（Strategy Pattern）** 就是专门用来优雅地处理这种“多种算法，一种目的”的情况的。它是一种行为设计模式，定义了一系列算法，并将每一个算法封装起来，使它们可以相互替换。策略模式让算法的变化独立于使用它的客户端。

简单说，它把“做什么”（任务）和“怎么做”（算法）分开了。我们可以在运行时，灵活地给“任务”更换不同的“做法”，而不用去修改“任务”本身的代码。
![Gemini_Generated_Image_yv9kbnyv9kbnyv9k.png](https://developer.qcloudimg.com/http-save/yehe-1367556/e77fb1e90e74f944b71eb2814660cd75.png)
# 遇到的问题
让我们想象一个具体的场景。我们正在开发一个导航应用的核心模块，它需要根据用户的选择（驾车、步行、骑行）来计算路线。
最初，我们可能会怎么写呢？很可能是一个巨大的 `RoutePlanner` 类，里面塞满了 `if-else` 或者 `switch-case`：
```
type RoutePlanner struct {
    // ... 一些属性
}

func (p *RoutePlanner) BuildRoute(start, end Point, transport string) Route {
    if transport == "driving" {
        // 一长串复杂的驾车路线算法代码
        return calculateDrivingRoute(start, end)
    } else if transport == "walking" {
        // 另一长串步行算法代码
        return calculateWalkingRoute(start, end)
    } else if transport == "cycling" {
        // 骑行算法代码
        return calculateCyclingRoute(start, end)
    }
    // ... 未来可能还有“公共交通”、“直升机”...
    panic("unknown transport type")
}
```

**问题立刻暴露出来了：**
1. **单一职责原则被破坏**：`RoutePlanner` 类变得无比庞大，它既要管理路线规划的逻辑框架，又要知道所有具体算法的实现细节。这违反了“一个类只负责一件事”的原则。
2. **难以维护和扩展**：每增加一种新的出行方式（比如“电动车”），我们就必须**修改**这个已经非常庞大的 `RoutePlanner` 类。这很容易引入错误，也使得这个类越来越难以阅读和理解。
3. **代码重复**：如果不同的算法有一些共同的初始化或校验步骤，这些代码可能会在各个分支里重复。
4. **运行时难以动态切换**：算法被硬编码在条件分支里，如果想在程序运行时根据路况、天气动态切换策略，会非常别扭。
# 解决方案
策略模式提供的解药是：**将算法抽取出来，封装成独立的策略类。**

具体怎么做呢？

1. **定义策略接口**：首先，我们为所有路线算法定义一个共同的接口，比如叫 `RoutingStrategy`，它只有一个核心方法 `BuildRoute(start, end Point) Route`。

2. **实现具体策略**：然后，我们为“驾车”、“步行”、“骑行”分别创建独立的类，比如 `DrivingStrategy`、`WalkingStrategy`、`CyclingStrategy`，它们都实现 `RoutingStrategy` 接口。

3. **改造上下文**：原来的 `RoutePlanner` 类（现在可以叫 `Navigator` 上下文）不再自己实现算法。它只需要持有一个 `RoutingStrategy` 接口类型的成员变量。

4. **委托执行**：当需要计算路线时，`Navigator` 只是简单地调用它当前所持有的策略对象的 `BuildRoute` 方法。它完全不知道也不关心具体是哪个策略在执行。

5. **动态设置策略**：我们可以给 `Navigator` 提供一个 `SetStrategy` 方法，让客户端（比如UI层）在运行时传入它想要的策略对象。

![Gemini_Generated_Image_3nex3nex3nex3nex.png](https://developer.qcloudimg.com/http-save/yehe-1367556/97d0818adf47c6a1eb20ddcee8da7a55.png)
这样一来，算法的实现和算法的使用就彻底**解耦**了。
# 应用场景
策略模式的应用非常广泛，几乎在任何需要“多种选择，一种行为”的地方都能看到它的身影。
- **支付系统**：一个订单结算，可以支持支付宝、微信支付、信用卡、数字货币等多种支付方式。每种支付方式的流程（验证、请求、回调）不同，但最终目的都是完成支付。
- **数据验证**：验证用户输入，规则可能很复杂：必填、长度、格式（邮箱、手机号）、业务逻辑校验（用户名是否重复）。我们可以为每种规则定义一个策略，并灵活组合。
- **压缩/序列化工具**：一个文件处理工具，可以支持 ZIP、TAR、RAR 等多种压缩算法，或者 JSON、XML、Protobuf 等多种序列化格式。
- **游戏AI**：游戏角色的攻击行为，可以根据情况在“近战攻击”、“远程射击”、“释放法术”等策略间切换。
- **文档渲染**：同一个数据，需要导出为 PDF、Word、HTML 等不同格式。

核心判断标准是：**你是否有一组相关的行为（算法），它们只是实现方式不同，但目标一致，并且你需要在运行时根据不同情况选择其中之一？**
# 代码示例
在Go里实现策略模式非常自然，因为Go推崇“组合优于继承”和“面向接口编程”。
1. **定义策略接口**：这是契约，所有具体策略都必须遵守。
```
type Strategy interface {
    Execute(a, b int) int // 这里以简单的数学运算为例
}
```

2. **实现具体策略**：创建不同的结构体来实现接口。
```
type AddStrategy struct{}
func (s *AddStrategy) Execute(a, b int) int {
    return a + b
}

type SubtractStrategy struct{}
func (s *SubtractStrategy) Execute(a, b int) int {
    return a - b
}

type MultiplyStrategy struct{}
func (s *MultiplyStrategy) Execute(a, b int) int {
    return a * b
}
```

3. **创建上下文**：上下文持有策略，并提供一个设置策略的方法。
```
type Context struct {
    strategy Strategy
}
func (c *Context) SetStrategy(s Strategy) {
    c.strategy = s
}
func (c *Context) ExecuteStrategy(a, b int) int {
    if c.strategy == nil {
        // 可以提供一个默认策略，或者panic/返回错误
        return 0
    }
    return c.strategy.Execute(a, b)
}
```

4. **客户端使用**：
```
func main() {
    ctx := &Context{}
    
    ctx.SetStrategy(&AddStrategy{})
    result := ctx.ExecuteStrategy(10, 5) // 输出 15
    
    ctx.SetStrategy(&MultiplyStrategy{})
    result = ctx.ExecuteStrategy(10, 5) // 输出 50
    
    fmt.Println(result)
}
```

新增一个除法策略？只需要创建一个新的 `DivideStrategy` 并实现 `Execute` 方法，然后 `SetStrategy` 进去就行了。`Context` 的代码一行都不用改。
# 优缺点
## **优点：**
- **开闭原则**：这是最大的优点。你可以轻松地引入新的策略，而无需修改使用策略的上下文或其他策略。系统扩展性变得非常好。
- **消除条件语句**：上下文类里不再有那些令人头疼的长长的 `if-else` 链，代码更简洁，职责更单一。
- **算法复用**：策略对象可以在不同的上下文环境中被复用。比如一个“日志格式化策略”，既可以在控制台输出器中使用，也可以在文件输出器中使用。
- **运行时灵活切换**：正如我们看到的，在程序运行时动态改变对象的行为变得非常简单。

## **缺点**
- **可能增加类/对象的数量**：如果算法本身很简单，而且数量很少（比如就两个，且永远不变），引入策略模式可能会让系统多出好几个类，显得有些“杀鸡用牛刀”。这时，简单的函数指针（在Go里是函数类型）或者Map映射可能更轻量。

- **客户端必须了解策略差异**：使用上下文的代码（客户端）需要知道有哪些策略可用，以及它们之间的区别，以便选择合适的策略。这可能会增加客户端的复杂度。

- **通信开销**：策略接口通常只定义一个方法。如果策略需要从上下文获取大量数据来运算，那么所有数据都必须通过参数传递。有时，这会导致策略接口的方法签名变得复杂。
# 总结

策略模式不仅仅是一种代码组织技巧，它更是一种**设计思维**的转变。它教会我们将“变”与“不变”分离，将“做什么”与“怎么做”解耦。

我们写代码时，是不是经常遇到一个场景：一个任务，有多种不同的完成方式？比如，给用户数据排序，有时按时间，有时按金额；计算运费，有时按重量，有时按体积；或者像文档里提到的，规划路线，可以开车、步行、坐公交。

策略模式-使用go语言实现

十倍工程师

后端

编程语言

架构设计

策略模式是一种优雅处理多种算法实现的设计模式，将算法封装成独立策略类，实现运行时动态切换。适用于支付方式、数据验证、压缩工具等场景，提升代码扩展性和可维护性。Go语言通过接口和组合完美实现策略模式，遵循开闭原则，消除条件语句，但需权衡类数量增加的问题。

游戏AI

JSON

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

策略模式-使用go语言实现-腾讯云开发者社区-腾讯云

策略模式-使用go语言实现

策略模式-使用go语言实现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐