2、正文部分
1
表驱动的意义
对于表驱动法，bug菌应该在之前的文章中经常有提及，常规做法就是定义一张表，该表一般就是一个结构体数组，结构体中包含查询的数据和数据对应的处理办法，在使用过程中通过查表数据，然后找到对应的处理方法来实现不同处理过程。
从功能上来看，表驱动法跟switch-case查询控制流程是非常相识的，但是表驱动法的优势在于数据与处理分离，一个合适的表结构，当工程师们扩展功能仅仅只需要添加相应的表项即可，一般不需要再改动表处理部分。
如果只是简单的使用switch-case，大量的case分支对程序的复杂度是明显增加的，非常不便于查找、排错和维护。
然而目前表驱动的设计大部分人都认为只有结构体数组这种固定方式，其实对于表项的组织还有两种也是非常常用的，下面bug菌就一一跟大家介绍。
2
三种表驱动设计
1
静态结构体数组式构建
这种表项的组织方式是大家了解表驱动法最早接触的，也是前面介绍得最多的，其他两种表驱动都仅仅只是在此法的基础上对表项进行更加灵活的组织。
表驱动法设计主要是两个方面 : 1）对象数据设计；2）对象关系设计。
下面是一个简单的菜单表驱动示例，也算是大家最常用的。
#include <stdio.h>
#include <stdlib.h>
typedef struct _tag_Menu stMenu;
struct _tag_Menu
{
char * MenuName;
void (*MenuPrepare)(void);
int (*MenuMessage)(void);
void (*MenuBack)(void);
//下面省略了相关界面相关数据区域
};
stMenu sMenu[] = {
{"Main UI",MainUIPrepare,MainUIMessage,MainUIBack},
{"Sec UI1",SecUI1Prepare,SecUI1Message,SecUI1Back},
{"Sec UI2",SecUI2Prepare,SecUI2Message,SecUI2Back},
{"Thd UI1",ThdUI1Prepare,ThdUI1Message,ThdUI1Back},
{"Thd UI2",ThdUI2Prepare,ThdUI2Message,ThdUI2Back}
};
int currMenu = 0;
int NextMenu = 0;
int main(int argc, char *argv[]) {
while(1)
{
NextMenu = sMenu[currMenu].MenuMessage(); //界面消息处理
if(NextMenu != currMenu) //需要进行界面切换
{
sMenu[currMenu].MenuBack(); //进行界面退出保存
sMenu[NextMenu].MenuPrepare(); //进行新界面的初始化准备
currMenu = NextMenu; //更新界面索引
}
}
return 0;
}以后如果需要添加新的菜单界面只需要修改驱动表项部分即可，而流程控制部分基本改动不大。
然而这样的表设计，每次的删减都需要动到全局的静态结构体数据表，为了尽量不直接修改公共部分，这里。
2
链表式构建
上面的数组是一片连续的静态区域，然而为了更好的增加表构建的灵活度，这里我们采用链表等非必须连续的数据结构来进行表项的组织，新模块仅仅只需要在初始化过程中添加链表结构即可。
而该链表中每一项与前面的数组项类似，使用过程中只要遍历链表即可获得相应的接口来进行对应的处理。
当然链表也只是其中一种组织方式，其他更快的遍历数据结构也是合适的。
3
链接式构建
读过Linux或者uboot源码的小伙伴这种方式应该都有了解过，该方式也是对数组表的改进，数组表可以看做程序员人为的把表项组织起来。
所以为了尽量减少人为的干预，只需要按照规定的格式编码并进行标记交给编译器去组织即可，同样编译器也会提供相应的标记，比如表的起始地址和结束地址，这样控制流就可以根据这些地址进行查表并获得相关参数。
如下是uboot中的相应处理，供大家参考:
1、每个模块中的cmd表项添加形式 :
2、U_BOOT_CMD宏的实现 :
3、对表项的遍历过程实现 :
3、结束语
好了，本文到此结束！希望本文能够给你带来一些收获！
