表驱动编程实战：让 UI 逻辑既清晰又好维护

在业务迭代频繁的项目里，我们常会遇到这样的代码：

cpp 复制代码

DrawLeftTopTire();   // 左前轮
DrawRightTopTire();  // 右前轮
DrawLeftBottomTire();
DrawRightBottomTire();

四个函数里大部分逻辑完全一样，只是坐标、图标名称不同。每次产品改一版 UI，我们就要复制粘贴地同步这四段代码，不仅累，还容易漏改。这时候，"表驱动（Table-driven）"就是很好的解法。

1. 什么是表驱动？

表驱动的核心思想是：把一系列相似逻辑的"变化点"抽成配置表，用结构体/数组描述。程序运行时，统一遍历这张"表"，调用通用逻辑处理每一条配置。

优点：

减少重复：逻辑只写一次。
修改成本低：改配置就能改变表现，不动代码。
更易扩展：新增场景只需加配置项。

这跟剧情脚本、配置驱动 UI、状态机表等思路一致，只是我们在普通 C++ 代码里应用它。

2. 实战示例：车辆状态窗口

以车况菜单为例，我们需要在屏幕上绘制四个轮胎的图标、数字。传统写法是四个函数；表驱动后，可以这么做：

cpp 复制代码

struct TireSlotCfg {
    DataModel* faultIcon;
    DataModel* pressureState;
    DataModel* pressureValue;
    ScreenPoint digitsPos;
    const char* normalIcon;
    const char* warningIcon;
    const char* normalDigits;
    const char* warningDigits;
};

static const TireSlotCfg kTireSlots[] = {
    { &mgr.TIRE_FAULT_FRONT_LEFT,  &mgr.TIRE_PRESSUREST_FRONT_LEFT,  &mgr.TIRE_FAULT_PRESSURE_FRONT_LEFT,
      {1425, 150}, "tier_nor", "tier_alarm", "tier_num", "tier_num_red" },
    // 右前、左后、右后同理......
};

static void DrawTires()
{
    for (const auto& slot : kTireSlots) {
        DrawTireSlot(slot);
    }
}

这样，绘制逻辑集中在 DrawTireSlot 一个函数里。要换坐标、换贴图、甚至增加第五个轮位，只需改表。

3. 表驱动还能做什么？

菜单列表：菜单项标题、图标、点击回调统一写在配置表里，渲染和事件处理都循环读取。
告警灯：每种告警包含"DataModel 指针 + 图标坐标 + 颜色"，循环渲染即可。
状态机 / 协议解析：状态、输入、next 函数都在表里，用 switch-case/if 的地方降维打击。

4. 实施建议

先找重复点 ：如果你见到左/右/前/后一组函数，几乎可以直接改成表驱动。
设计配置结构：抽出真正的"变化参数"，写成结构体。
集中管理表：像 ADAS 模块那样，把所有配置放在文件顶部，便于查阅。
保留现有风格 ：如果团队习惯 static 函数 + 匿名 namespace，可以沿用，只是多了配置数组；不用强求上来就引入大量类。
加注释：哪怕表驱动再漂亮，没有注释也很难维护。表的含义、单位、坐标体系尽量写清楚。

5. 小结

表驱动不是高级技巧，但在 UI、渲染、状态机等重复逻辑中尤其有效。它让"改坐标/换图片"这种要求变得轻松，也让代码更易于理解。下一次当你看到一堆功能类似的函数或分支，不妨试试把它们变成一张"表"。