所谓表驱动法(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<K,V> 就是一个典型的例子
C#代码 获取一个用户对象
Dictionary<string,User> 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(double score) { int level = 0; while (level <= maxLevel) { if (score < rangeLimit[level]) { return grade[level]; } else level++; } return grade[maxLevel]; }
比如我们要用C写一个判断语句,然后根据不同的值返回不同的内容。
1 2 3 4 5 6 7 8 9 10 11 12 |
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类比,这里没有用字典):
1 2 3 4 5 6 |
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里面是否能同样的方法实现呢,是可以的:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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并不能胜任。
一个很经典的例子:C实现实现打印LED灯,看以前的:http://www.cnblogs.com/youxin/p/3281767.html。
一篇好的文章:
《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 ", 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 ", msg_type);
}
下面这种思路的优势:
1、可读性更强,消息处理流程一目了然。
2、更容易修改,要增加新的消息,只要修改数据即可,不需要修改流程。
3、重用,第一种方案的很多的else if其实只是消息类型和处理函数不同,但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来,而把容易发生变化的部分提到外面。
隐含在背后的思想:
很多设计思路背后的原理其实都是相通的,隐含在数据驱动编程背后的实现思想包括:
1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来,从而达到控制复杂度的目标。
2、隔离变化。像上面的例子,每个消息处理的逻辑是不变的,但是消息可能是变化的,那就把容易变化的消息和不容易变化的逻辑分离。
3、机制和策略的分离。和第二点很像,本书中很多地方提到了机制和策略。上例中,我的理解,机制就是消息的处理逻辑,策略就是不同的消息处理(后面想专门写一篇文章介绍下机制和策略)。
数据驱动编程可以用来做什么:
如上例所示,它可以应用在函数级的设计中。
同时,它也可以应用在程序级的设计中,典型的比如用表驱动法实现一个状态机(后面写篇文章专门介绍)。
也可以用在系统级的设计中,比如DSL(这方面我经验有些欠缺,目前不是非常确定)。
它不是什么:
1、 它不是一个全新的编程模型:它只是一种设计思路,而且历史悠久,在unix/linux社区应用很多;
2、它不同于面向对象设计中的数据:“数据驱动编程中,数据不但表示了某个对象的状态,实际上还定义了程序的流程;OO看重的是封装,而数据驱动编程看重的是编写尽可能少的代码。”
书中的值得思考的话:
数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条,正确的算法就不言自明。编程的核心是数据结构,而不是算法。——Rob Pike
程序员束手无策。。。。。只有跳脱代码,直起腰,仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks
数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者
转自:http://www.cnblogs.com/chgaowei/archive/2011/08/03/2126724.html
另一篇文章:
数据即代码:元驱动编程 coolshell。
另一篇:http://www.blogjava.net/killme2008/archive/2008/04/17/193852.html