所谓表驱动法(Table-Driven Approach),简单讲是指用查表的方法获取值。

我们平时查字典以及念初中时查《数学用表》找立方根就是典型的表驱动法。在数值不多的时候我们可以用逻辑语句(if 或case)的方法来获取值,但随着数值的增多逻辑语句就会越来越长,此时表驱动法的优势就显现出来了。

查表的方式

在使用表驱动法的时候必须要解决的一个问题就是如何查表.

我们可以用非常直接的方式查一个表,就如前面示例讲的我就用数组下标就好了,但你发现有谁查字典甚至《数学用表》是直接依靠页码来查的吗?这是肯定行不通的。

常用的查表方式有

直接查询

索引查询

分段查询

直接查询，是指无需绕圈子，用下标的方式就能顺利的获取到数据；

C#代码 表驱动法获取星期名称

string[] dayNames=new string[]{"星期日","星期一","星期二","星期三","星期四","星期五","星期六"};

dayName=dayNames[day];

只要一条语句就可以代替长长的if-else语句

如果某一天我们的网站要根据访客选择的语言来显示星期几的话

表驱动法仍然很简单

C#代码 表驱动法获取星期名称

dayName=dayNames[day,(int)GetUserLanguage()];

但如果是用if-else的话,那长度可就的翻番啊。

3.2 索引查找 key

在用一个简单方法无法将“英文单词”这样数据转换成表下标时,可以考虑使用索引来查找.在.net中的Dictionary 就是一个典型的例子

C#代码 获取一个用户对象

Dictionary users=GetAllUsers();

User tom=users["Tom"];

其实我们常用的DataTable就可以用索引查找的方式来获取数据

假如有个人员信息的table

C#代码 用索引查找方式从DataTable中获取第一个用户的姓名

DataTable userInfo=dal.GetAllUsersInfo();

name=userInfo.Rows[0].Columns["UserName"];

使用索引查询的主要优点就是代码的可读性大为增强,可维护性也更好

C#代码 用直接查找方式从DataTable中获取第一个用户的姓名

DataTable userInfo=dal.GetAllUsersInfo();

name=userInfo.Rows[i].Columns[3];

对比上一段代码,columns[3]很让人不知所谓;此外如果返回的Datable返回的列顺序改变的话就必须更改魔术数字3,否则代码就会出错;

分段查找

分段查找通过确定数据所处的范围确定分类(下标)

使用分段查找,需要先把每一个区间的上限写在一个表中,然后通过循环确定所处的区段,最后获得相应的等级

C#示例 根据分数查绩效等级

private static double[] rangeLimit = { 60.0, 75.0, 85.0, 95.0,100.0};private static string[] grade = {"不合格", "合乎要求", "良好", "优秀" ,"卓越"};private static readonly int maxLevel = grade.Length - 1;public static string CalculateGrade(doublescore)

{int level = 0;while (level <=maxLevel)

{if (score

{returngrade[level];

}else level++;

}returngrade[maxLevel];

}

比如我们要用C写一个判断语句，然后根据不同的值返回不同的内容。

if(1 == val)

{

return "this is one";

}

else if(2 == val)

{

return "this is two";

}

else if(3 == val)

{

return "this is three";

}

如果判断的逻辑很多，代码就会显得很臃肿(文中的例子用switch也可以，但是也还是很难看)，如果用python，就会这样写(为了和C类比，这里没有用字典):

datas = [

(1,"this is one"),(2,"this is two"),(3,"this is three")

]

for v in datas:

if v[0] == val:

return v[1]

那在c里面是否能同样的方法实现呢，是可以的:

struct

{

int key;

string strdata;

}arr_datas[]={

{1,"this is one"},

{2,"this is two"},

{3,"this is three"},

};

for (i = 0; i < 3; i++)

{

if (arr_datas[i].key == val)

{

return arr_datas[i].strdata;

}

}

附:

有人可能想到用stl的map，查找速度会快一些，不过想到定义一个map，然后调用一堆insert其实也挺麻烦的，而且例子中用的是int，但是并不是所有的类型都是可hash的，所以有些情况下map并不能胜任。

一篇好的文章:

《Unix编程艺术》在介绍Unix设计原则时，其中有一条为“表示原则：把知识叠入数据以求逻辑质朴而健壮”。

数据驱动编程的核心

数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。数据比程序逻辑更容易驾驭，所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。

真的是这样吗？让我们来看一个示例。

假设有一个程序，需要处理其他程序发送的消息，消息类型是字符串，每个消息都需要一个函数进行处理。第一印象，我们可能会这样处理：

void msg_proc(const char *msg_type, const char *msg_buf)

{

if (0 == strcmp(msg_type, "inivite"))

{

inivite_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "tring_100"))

{

tring_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_180"))

{

ring_180_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_181"))

{

ring_181_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_182"))

{

ring_182_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ring_183"))

{

ring_183_fun(msg_buf);

}

else if (0 == strcmp(msg_type, "ok_200"))

{

ok_200_fun(msg_buf);

}

。。。。。。

else if (0 == strcmp(msg_type, "fail_486"))

{

fail_486_fun(msg_buf);

}

else

{

log("未识别的消息类型%s\n", msg_type);

}

}

上面的消息类型取自sip协议(不完全相同，sip协议借鉴了http协议)，消息类型可能还会增加。看着常常的流程可能有点累，检测一下中间某个消息有没有处理也比较费劲，而且，没增加一个消息，就要增加一个流程分支。

按照数据驱动编程的思路，可能会这样设计：

typedef void (*SIP_MSG_FUN)(const char *);

typedef struct __msg_fun_st

{

const char *msg_type;//消息类型

SIP_MSG_FUN fun_ptr;//函数指针

}msg_fun_st;

msg_fun_st msg_flow[] =

{

{"inivite", inivite_fun},

{"tring_100", tring_fun},

{"ring_180", ring_180_fun},

{"ring_181", ring_181_fun},

{"ring_182", ring_182_fun},

{"ring_183", ring_183_fun},

{"ok_200", ok_200_fun},

。。。。。。

{"fail_486", fail_486_fun}

};

void msg_proc(const char *msg_type, const char *msg_buf)

{

int type_num = sizeof(msg_flow) / sizeof(msg_fun_st);

int i = 0;

for (i = 0; i < type_num; i++)

{

if (0 == strcmp(msg_flow[i].msg_type, msg_type))

{

msg_flow[i].fun_ptr(msg_buf);

return ;

}

}

log("未识别的消息类型%s\n", msg_type);

}

下面这种思路的优势：

1、可读性更强，消息处理流程一目了然。

2、更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。

3、重用，第一种方案的很多的else if其实只是消息类型和处理函数不同，但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来，而把容易发生变化的部分提到外面。

隐含在背后的思想：

很多设计思路背后的原理其实都是相通的，隐含在数据驱动编程背后的实现思想包括：

1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

2、隔离变化。像上面的例子，每个消息处理的逻辑是不变的，但是消息可能是变化的，那就把容易变化的消息和不容易变化的逻辑分离。

3、机制和策略的分离。和第二点很像，本书中很多地方提到了机制和策略。上例中，我的理解，机制就是消息的处理逻辑，策略就是不同的消息处理(后面想专门写一篇文章介绍下机制和策略)。

数据驱动编程可以用来做什么：

如上例所示，它可以应用在函数级的设计中。

同时，它也可以应用在程序级的设计中，典型的比如用表驱动法实现一个状态机(后面写篇文章专门介绍)。

也可以用在系统级的设计中，比如DSL(这方面我经验有些欠缺，目前不是非常确定)。

它不是什么：

1、 它不是一个全新的编程模型：它只是一种设计思路，而且历史悠久，在unix/linux社区应用很多；

2、它不同于面向对象设计中的数据：“数据驱动编程中，数据不但表示了某个对象的状态，实际上还定义了程序的流程；OO看重的是封装，而数据驱动编程看重的是编写尽可能少的代码。”

书中的值得思考的话：

数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike

程序员束手无策。。。。。只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks

数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者

另一篇文章：

数据即代码：元驱动编程 coolshell。