翻开任意一份有点规模的嵌入式代码仓库，grep _ops 一下，出来的结果往往多到让人忽略它的存在。uart_ops、flash_ops、sensor_ops、net_ops、log_ops……它们散落在驱动层、中间件、应用框架里，像水电煤一样成了基础设施的一部分。
奇怪的是，越是用得熟的人，越容易把它当成一种“约定俗成”的写法——前辈这么写，Linux 内核这么写，所以我也这么写。少有人认真追问过一件事：为什么几乎所有稍微讲究一点的嵌入式工程，都会不约而同地演化出 xxx_ops 这种形态？这是惯性，还是必然？
我自己在写了几年嵌入式、踩过几次“改一处动一片”的坑之后，才逐渐觉得 ops 句柄这个设计不是顺手而为，而是一个非常克制又非常到位的工程解法。它看起来只是一个塞满函数指针的结构体，但它替 C 语言这门不支持多态的语言，悄悄补上了工业级软件最需要的那一层——接口。
这篇文章想做的事情不是教你“怎么写一个 ops”——那种模板随便一搜一大把，而是反过来追问:
- ops 句柄到底替我们回答了什么设计问题？
- 一个“好”的 ops 和一个“差”的 ops，差在哪里？
- 那些看起来可选可不选的细节——要不要 self 指针、NULL 检查还是默认实现、单层还是分层——背后其实都在权衡什么？
如果你也在维护一份 ops 塞得到处都是的代码，或者正准备给自己的模块加一层 ops，希望这篇能让你下一次动笔时，脑子里多一点“为什么”。关于其中涉及的设计模式思想，值得深入体会。
一、ops 句柄到底是什么
最直白的定义：一个把函数指针组织成“一组操作”的结构体，加上使用它的那套约定。
比如一个极简版本：
struct sensor_ops {
int (*init) (void *ctx);
int (*read) (void *ctx, int *value);
int (*close)(void *ctx);
};
这里有三个细节，每一个都不是随便写的：
- 它是 struct 而不是一堆散落的函数。几个函数被“绑”在一起，传一个 struct 指针就相当于传递一整套能力。
- 它用函数指针而不是直接写函数。同一个
sensor_ops 可以指向温度传感器的实现、也可以指向加速度传感器的实现——调用者不关心。
- *每个函数几乎都带一个 `void ctx
**。因为 C 没有隐式的this`，每个操作需要一个显式的“自己”。
但这只是形，不是神。ops 句柄真正在做的事情，是在 C 语言里画出一条接口线。
用一张图看会更清楚：
这条接口线带来的变化是什么？调用者不再“认识”任何具体实现。它只认识 sensor_ops。你替换、升级、再加一个新传感器，调用者一行代码都不用动。
如果你熟悉 Java 或 C++，你会一眼认出：这就是 interface / 纯虚基类，只不过搬到了 C 里。但这里有一个关键区别值得反复强调——在 Java/C++ 里，接口是语言替你“内置”的，编译器会帮你生成 vtable、做动态分发；而在 C 里，ops 句柄是你手工搭出来的 vtable。你控制它的每一个字节：布局、生命周期、可见性、加载时机，全由你自己安排。
这一点在裸机或 RTOS 环境下至关重要：没有运行时、没有 GC、连堆都可能不敢用。你需要一个可控到字节的多态机制，函数指针 + 结构体，是你能拿到的最轻、最透明、最可预测的那个。
所以下一次看到 xxx_ops，别只把它读作“结构体”，把它读作：“这里有一条接口边界”。理解了这一层，后面所有的设计决策才有落点。
二、为什么一定要这么设计
很多人在写 ops 的时候是“照抄”的——看着 Linux 的 file_operations 依样画葫芦。照抄没错，但如果不明白每一步为什么这样走，等你自己从零设计一个模块时，就会开始做莫名其妙的选择：比如把 ops 里的函数指针拆回全局函数、比如把 self 参数砍掉省几行代码。
这里把三个关键“为什么”拆开说。
为什么非得是结构体
假设你写了一个 SPI Flash 驱动，它对外提供 init / read / write / erase。不用结构体的话，接口长这样：
int flash_init(void);
int flash_read (uint32_t addr, uint8_t *buf, size_t n);
int flash_write(uint32_t addr, const uint8_t *buf, size_t n);
int flash_erase(uint32_t addr, size_t n);
看起来也挺清爽。直到产品要同时支持两种 Flash——板载的 NOR 和外挂的 NAND，上层代码要能在运行时切换。
没有 ops 结构体，你只能开始写 if (type == NOR) flash_nor_read(...); else flash_nand_read(...);，而且每个入口都要写一遍。加第三种 Flash 的时候，上层要改四次，四个位置任一漏改就是一个 bug。
把它们打包成 struct flash_ops 之后：
static const struct flash_ops nor_ops = { nor_init, nor_read, ... };
static const struct flash_ops nand_ops = { nand_init, nand_read, ... };
const struct flash_ops *ops = pick_by_board();
ops->read(ctx, addr, buf, n);
结构体把“同一组操作”打包成一个可被当作整体传递的值。这才是 ops 要用 struct 的真正原因——不是为了好看，是为了能整体替换。
为什么非得是函数指针
函数指针的作用是“延迟绑定”——调用者写代码的时候，它不知道、也不需要知道最终会调到哪一个实现。绑定发生在运行时，而不是编译时。
听起来挺虚，看个反例就懂了：如果把 ops->read 换成 flash_read（直接调具体函数名），意味着你在编译期就把调用者和一个特定实现焊死了。想换实现？要么改代码，要么加一堆 #ifdef——后者正是很多老项目让人窒息的根源。
函数指针把“用这个函数”和“这个函数是谁”解耦了。调用者只声明需求，实现方负责填坑。
为什么非得有 self / ctx 参数
C 语言没有 this，但业务世界里几乎所有操作都需要知道“对谁做这件事”。同一个 UART 驱动会同时服务三路串口，uart_write() 不知道写给哪一路，这代码是废的。
于是 ops 函数的第一个参数几乎永远是一个 self 指针（名字可能叫 ctx、dev、self、priv）：
int (*read)(void *self, uint8_t *buf, size_t n);
这个 self 承载的是“实例状态”——硬件寄存器基址、缓冲区、统计计数、配置字……。ops 句柄里放的是“类级别”的函数表，self 指针传递的是“对象级别”的数据。两者一组合，就是 C 里最朴素的面向对象。
写到这里你大概能感觉到——ops 句柄这三个构件不是随便搭的，它们精确对应了“接口 / 多态 / 实例”三个面向对象里的概念。C 没有语法糖，所以你得自己把这三件事用结构体、函数指针、self 指针手工拼出来。
三、好 ops 和差 ops 的分水岭
见过的 ops 设计里，差距最大的不是“有没有”，而是“怎么切”。同样一个模块，有人切得好用了五年还在用，有人切完三个月就想推倒重来。这里拆四个决策点。
决策一：粒度——一个 ops 塞多大
这是最容易翻车的地方。两种常见极端：
- 巨无霸 ops：把模块所有能想到的操作全塞进去，二十几个字段起步。问题是一旦某个实现不支持其中一半，就得大面积放 NULL，调用前还得挨个检查。
- 碎片 ops：一个模块拆出三五个小 ops，
xxx_base_ops、xxx_ext_ops、xxx_debug_ops……表面上“职责单一”，但调用者要同时持有好几个句柄，心智负担陡增。
一个可操作的经验是：以“一种典型调用者关心的最小闭环”为粒度。读传感器的闭环通常是 init → read → close，那就把这三个放在主 ops 里；校准、自检这些低频操作，单独放一个 sensor_calib_ops，按需要才引用。
决策二：可选操作——NULL 检查 vs 默认实现
模块的某些操作天生是可选的。比如有的传感器有低功耗模式、有的没有。ops 里的 enter_low_power 字段怎么处理？
两条路：
A. 允许字段为 NULL，调用前检查：
if (ops->enter_low_power)
ops->enter_low_power(ctx);
B. 未实现的统一指向一个空操作 / 默认实现：
static int noop_lp(void *ctx) { (void)ctx; return 0; }
static const struct sensor_ops default_ops = { .enter_low_power = noop_lp, ... };
初看 A 更省事，但随着调用点变多，NULL 检查会散落在各处，漏一个就是 crash。B 前期多写几行默认实现，但调用侧永远是 ops->xxx() 一条干净的路径。
我的取向是：对外暴露的、调用点分散的 ops，优先用默认实现兜底；只在模块内部、调用点集中的地方才考虑 NULL 语义。默认实现把“可选性”封装进了 ops 自己，调用者不必为它的复杂性付代价。
决策三：单层 ops vs 多层 ops
当模块本身有层次——比如一个“协议栈”既有链路层又有会话层——ops 是拍平还是分层？
拍平的好处是结构清晰、调用栈浅；分层的好处是每一层都能独立替换，但代价是调用路径变长、调试时要多跳几层。
判断标准我一般看两条：这两层是否会独立演化、是否有独立的测试需求。都满足，就分层；否则拍平更省力。过度分层会让代码看起来很“设计”，但实际维护起来每改一处要翻三个文件。
决策四：ops 实例的生命周期和可见性
最后一件事——ops 的那个 struct 实例，到底该放在哪？
三种常见形态：
- 只读全局变量 + const 修饰：
static const struct xxx_ops xxx_ops = {...};。最常见、最安全，编译器会把它放到只读段，防止被意外改写。默认就这么写。
- 可变全局变量：偶尔会看到有人把 ops 做成运行时可修改的，为了做 hook 或动态注入。能用但要极度克制，一旦多线程进来就是定时炸弹。
- 堆上分配 + 引用计数：ops 模板按需复制、带生命周期管理。这种设计在大型框架里才用得上，嵌入式里基本是杀鸡用牛刀。
如果你拿不准，先按第一种写，ops 表一律 const。const 能帮你挡掉一大类“莫名其妙被改了”的 bug，而且零成本。
四、几个真实踩过的坑
最后说几个特别容易翻车的点，都是我或身边同事实打实撞过的。
坑一：函数签名“各自为政”。同一个 ops 表里，几个实现的参数顺序、错误码含义、阻塞/非阻塞语义各玩各的，调用者永远猜不到这次调用到底会不会阻塞。这不是实现的问题，是在设计 ops 的时候，没给签名立规矩。ops 表的本质是契约，契约出了分歧，所有接入方都要替你擦屁股。
坑二：忘了 const，导致 ops 表被改写。见过最恶心的 bug 是：一个同事调试时为了注入 mock，临时改了某个 ops 字段，然后忘了恢复——代码走到发布都没发现，直到现场一复现，花了两天定位。加 const、放 .rodata 段，就没这个故事。
坑三：把“私货”塞进 ops。ops 表里本应只有“语义级别”的操作，偶尔会有人为图省事塞个 get_raw_register_ptr 之类的内部细节进来。一旦这样，ops 就不再是接口，而成了“上下层强耦合的输水管”。抽象会立刻漏水，也就失去了它存在的意义。
五、ops 背后其实是一整套设计思想
写到这里你应该能意识到一件事：ops 句柄看起来是 C 语言的一个小技巧，但它回答的问题——如何让调用者和实现解耦、如何让一组行为可被整体替换、如何用最轻的代价支持多态——其实是设计模式这个更大话题里反复出现的母题。
把 ops 翻译到设计模式的语言：
- 运行时根据场景换一个 ops 表 ⇒ 策略模式（Strategy）
- 上层固定主流程、具体几个步骤交给 ops 实现 ⇒ 模板方法（Template Method）
- 根据配置 / 板型选择返回哪一个 ops 实例 ⇒ 简单工厂（Simple Factory）
嵌入式工程师里有一个普遍的误解：设计模式是 Java / C++ 程序员的玩具，写 C 的用不着。恰恰相反——越是语言层面贫瘠、资源越受限的环境，你越需要借助模式去压榨出结构。ops 句柄就是最好的例证：它把策略 + 模板方法 + 工厂这三种思想，用结构体加函数指针这最朴素的材料，实打实地落进了一块几十 KB 的固件里。
所以比“会用 ops”更重要的，是理解 ops 背后那套从模式里抽出来的思维方式。一旦你能在脑子里同时调用几种模式去看一段代码，你看到的就不再是“函数指针填表”，而是一张张可以互相组合、可以迁移到任何语言的设计地图。要深入理解这些模式在 C/C++ 嵌入式下的落地方式，可以进一步研究相关的设计模式与架构思想。
发表于 2 小时前
|
查看: 4|
回复: 0
