第 4 篇：策略模式 (Strategy) —— 算法的热插拔艺术-平芜编程栈

专栏导读：你是否遇到过这种崩溃瞬间：产品卖给 A 客户要用 Modbus 协议，卖给 B 客户要用私有协议，卖给 C 客户要加密传输。你的代码里是不是充斥着无数的#ifdef CUSTOMER_A或者if (mode == 1)？策略模式教你用 C 语言实现“多态”，让算法像 USB 设备一样，插上就能用，拔掉就消失。

1. 场景还原 (The Pain)

假设你正在维护一款智能门锁。核心功能是“验证密码”。起初，只需要简单的明文比对。后来，高配版加入了指纹（Hash 校验），海外版要求符合安全规范（CRC32 或 AES）。

菜鸟的写法：条件判断的地狱

typedef enum { AUTH_SIMPLE, AUTH_CRC32, AUTH_HASH } AuthMode;

bool Verify_Password(uint8_t* input, uint8_t* stored, int len, AuthMode mode) {
if (mode == AUTH_SIMPLE) {
// 明文比对
return (memcmp(input, stored, len) == 0);
}
else if (mode == AUTH_CRC32) {
// 还要去包含 CRC 的头文件，耦合严重
uint32_t crc_in = Cal_CRC32(input, len);
uint32_t crc_store = *(uint32_t*)stored;
return (crc_in == crc_store);
}
else if (mode == AUTH_HASH) {
// ... 又是一大坨代码 ...
}
return false;
}

架构师的审视

这种代码违反了设计模式的最高天条：开闭原则 (Open-Closed Principle)—— 对扩展开放，对修改关闭。

耦合过重：Verify_Password函数必须认识所有的算法。如果你要加一个新的“视网膜扫描”，你得修改这个经过测试的稳定函数，万一改坏了，旧功能也挂了。
代码臃肿：低配版芯片 Flash 只有 32KB，根本装不下 AES 库，但因为写在一个文件里，链接器很难剥离未用到的代码（除非编译器优化极强）。

2. 模式图解 (The Concept)

策略模式的核心是将**“做什么” (Interface)** 和“怎么做” (Implementation)分离。

Context (环境)：持有算法的指针，不关心具体是哪个算法。
Strategy (接口)：定义一套标准的函数指针结构体（V-Table）。
Concrete Strategy (具体策略)：实现具体的算法。

3. 代码实战 (The Code)

C 语言实现多态的秘密武器：结构体 + 函数指针。

3.1 定义接口 (The Interface)

这是所有算法必须遵守的契约。

// IValidator.h
#include <stdint.h>
#include <stdbool.h>

// 前置声明，类似 C++ 的 this 指针
typedef struct Validator_t Validator;

// 策略接口定义 (虚函数表)
typedef struct {
// 初始化算法
void (*init)(Validator* self);
// 执行计算
uint32_t (*calculate)(Validator* self, const uint8_t* data, uint32_t len);
// 销毁/清理 (可选)
void (*deinit)(Validator* self);
} ValidatorOps;

// 基类结构体
struct Validator_t {
const ValidatorOps* ops; // 指向虚表的指针
// 可以添加公共属性，如超时时间等
uint32_t timeout;
};

3.2 具体策略实现 (Concrete Strategies)

我们把每个算法写在独立的.c文件里，互不干扰。

策略 A：简单校验 (Simple)

// Validator_Simple.c
#include "IValidator.h"

static uint32_t simple_cal(Validator* self, const uint8_t* data, uint32_t len) {
uint32_t sum = 0;
for(int i=0; i<len; i++) sum += data[i];
return sum; // 简单的累加和
}

// 定义具体的虚表
static const ValidatorOps s_simple_ops = {
.init = NULL, // 不需要初始化
.calculate = simple_cal,
};

// 构造函数
void Validator_Simple_Init(Validator* v) {
v->ops = &s_simple_ops; // 核心：绑定指针
}

策略 B：CRC32 校验 (CRC32)

// Validator_CRC32.c
#include "IValidator.h"
#include "stm32_crc.h" // 依赖硬件库

static void crc_init(Validator* self) {
__HAL_RCC_CRC_CLK_ENABLE(); // 开启硬件时钟
}

static uint32_t crc_cal(Validator* self, const uint8_t* data, uint32_t len) {
return HAL_CRC_Calculate(&hcrc, (uint32_t*)data, len);
}

static const ValidatorOps s_crc32_ops = {
.init = crc_init,
.calculate = crc_cal,
};

void Validator_CRC32_Init(Validator* v) {
v->ops = &s_crc32_ops;
}

3.3 业务调用 (Context)

// main.c
#include "IValidator.h"

// 全局的校验器实例
Validator g_current_validator;

// 根据配置选择策略 (Factory 模式的雏形)
void System_Init() {
uint8_t config = Read_Flash_Config();

if (config == MODE_HIGH_END) {
Validator_CRC32_Init(&g_current_validator);
} else {
Validator_Simple_Init(&g_current_validator);
}

// 初始化选定的算法
if (g_current_validator.ops->init) {
g_current_validator.ops->init(&g_current_validator);
}
}

// 业务逻辑：完全不需要知道底层是 CRC 还是 Sum
bool Verify_Packet(uint8_t* data, int len, uint32_t expected) {
// 多态调用！
uint32_t result = g_current_validator.ops->calculate(&g_current_validator, data, len);

return (result == expected);
}

4. 内存与性能分析 (The Cost)

空间开销

Flash: 这种写法对 Linker 非常友好。如果你在System_Init里没有调用Validator_CRC32_Init，聪明的链接器（开启--gc-sections）会自动把Validator_CRC32.c的代码完全剔除。这就实现了**“用多少，链多少”**。
RAM: 每个策略实例只需要一个指针大小（4 字节）。虚表ValidatorOps声明为const，存放在 Flash 中，不占 RAM。

时间开销

间接调用:ops->calculate(...)是一次间接函数调用 (Indirect Call)。
汇编视角:
- 直接调用：BL 0x08001234(跳转到固定地址)
- 间接调用：LDR R0, [R1]; BLX R0(先读地址再跳转)
性能损耗: 相比直接调用，多了 2-3 个指令周期。
架构师建议:不要在百万次的极速循环内部使用策略模式（例如像素级渲染）。但对于通信包校验、按键处理、传感器读取这种毫秒级任务，性能损耗可以忽略不计，换来的是巨大的架构灵活性。