表驱动方法（Table-Driven Methods） - winner_0715 - 博客园 https://www.cnblogs.com/winner-0715/p/9382048.html
What
表驱动方法（Table-Driven Methods），在《Unix 编程艺术》中有提到，《代码大全》的第十八章对此进行了详细地讲解。
表驱动法是一种编程模式（Scheme），从表里面查找信息而不使用逻辑语句（if 和case） 它的好处是消除代码里面到处出现的if、else、swith语句，让凌乱代码变得简明和清晰。
对简单情况而言，表驱动方法可能仅仅使逻辑语句更容易和直白，但随着逻辑的越来越复杂，表驱动法就愈发有吸引力。
if...else...比较多的时候就想想表驱动法...
Why
先通过一个简单的例子体验下，在某些情况下，如果不使用表驱动方法，代码会如何地难看。
假设让你实现一个返回每个月天数的函数（为简单起见不考虑闰年）。
初级码农的笨方法是马上摆出 12 副威武雄壮的 if-else 组合拳：
int iGetMonthDays(int iMonth){
int iDays;
if(1 == iMonth) {iDays = 31;}
else if(2 == iMonth) {iDays = 28;}
else if(3 == iMonth) {iDays = 31;}
else if(4 == iMonth) {iDays = 30;}
else if(5 == iMonth) {iDays = 31;}
else if(6 == iMonth) {iDays = 30;}
else if(7 == iMonth) {iDays = 31;}
else if(8 == iMonth) {iDays = 31;}
else if(9 == iMonth) {iDays = 30;}
else if(10 == iMonth) {iDays = 31;}
else if(11 == iMonth) {iDays = 30;}
else if(12 == iMonth) {iDays = 31;}
return iDays;
}稍微机灵点的码农发现每月天数无外乎 28、30、31 三种，或许会用 switch-case “裁剪”下：
int iGetMonthDays(int iMonth){
int iDays;
switch (iMonth) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:{iDays = 31;break;}
case 2:{iDays = 28;break;}
case 4:
case 6:
case 9:
case 11:{iDays = 30;break;}
}
return iDays;
}这两种方法充斥了大量的逻辑判断，还凭空冒出了一大堆1，2，...，11，12这样的 Magic Number（魔鬼数字公然出现在程序里是很 ugly 的做法），不利于代码的维护与扩展。
表驱动处理起来就赏心悦目得多了：
static int monthDays[12] = {31,28,31,30,31,30,31,31,30,31,30,31};
int iGetMonthDays(int iMonth){
return monthDays[(iMonth - 1)];
}How
表驱动可以使你的代码更简洁，结构更加灵活，多用于逻辑性不强但是分支多的情况。
如何使用表驱动法？需要明确两个关键问题：
表的形式及表中放什么内容
- 表形式可以为一维数组、二维数组和结构体数组。
- 表中可以存放数值、字符串或函数指针等数据。
如何去访问表。
下面介绍表的三种访问方式：
直接访问
直接根据“键”来获得“值”，给定下标 index，然后array[index]就获得数组在相应下标处的数值。例如前面这个根据月份取天数的例子。
索引访问
它适用于这样的情况：假设你经营一家商店，有 100 种商品，每种商品都有一个 ID 号，但很多商品的描述都差不多，所以只有 30 条不同的描述，如何建立建立商品与商品描述的表？
还是同上面做法来一一对应吗？那样描述会扩充到 100 个，会有 70 个描述是重复的！太浪费了。
方法是建立一个 100 长的索引和 30 长的描述，然后这些索引指向相应的描述（不同的索引可以指向相同的描述），这样就解决了表数据冗余的问题啦。
struct product_t {
char * id;
int desc_index;
};
const char * desc[] = {
"description_1",
"description_2",
...
"description_29",
"description_30"
};
const product_t goods [] = {
{"id_1", 3},
{"id_2", 1},
...
{"id_99", 12},
{"id_100", 5}
};
const char* desc_product (const char* id) {
for (const product_t & p : goods) {
if (strcmp(p.id, id) == 0) {
return desc[p.desc_index - 1];
}
}
return NULL;
}阶梯访问
例子：将百分制成绩转成五级分制（我们用的优、良、中、合格、不合格，西方用的 A、B、C、D和F），假定转换关系:
| [90-100] | A |
| [80,90) | B |
| [70,80) | C |
| [60,70) | D |
| [0,60) | F |
如何用表格表示这些范围？你当然可以用第一种直接访问的方法：申请一个 100 长的表，然后在这个表中填充相应的等级。很明显，也会浪费大量空间，有没有更好的方法？
对于这种“某个范围区间内，对应某个值”的逻辑规则，可用阶梯访问的方式。
const char gradeTable[] = {
'A', 'B', 'C', 'D', 'F'
};
const int downLimit[] = {
90, 80, 70, 60
};
int degree(int score)
{
int gradeLevel = 0;
char lowestDegree = gradeTable[sizeof(gradeTable)/sizeof(gradeTable[0]) - 1];
// 这里可用二分查找优化
while (gradeTable[gradeLevel] != lowestDegree) {
if(score < downLimit[gradeLevel]) {
++ gradeLevel;
} else {
break;
}
}
return gradeTable[gradeLevel];
}将来如果等级规则变了（比如 85～100 分为等级 A，或添加 50～60 分为等级 E），只需要修改 gradeTable 和 downLimit 表就行，degree 函数可以保持一行都不改动。
更进一步地，gradeTable 和 downLimit 表还可以配置文件的形式表示，主程序从外部文件 load 进来就行，程序灵活性大大增加。
Review
伟大的 C 语言大师 Rob Pike 有句话说的好：
对人类来说，数据比编程逻辑更容易驾驭。在复杂数据和复杂代码中选择，宁可选择前者。
更进一步，在设计中，应该主动将代码的复杂度转移到数据中去。
这里谈到了 Unix 哲学之分离原则：
机制，即提供的功能。
策略，即如何使用功能。
以百分制转五级分制为例，机制就是 degree 函数：你给一个百分制分数给它，它吐出来一个五级分制给你。策略就是gradeTable 和 downLimit 这两个表，它规定了哪个区间的分数对应哪个等级。
从 degree 的实现可以看出:对机制而言，策略是透明的（degree 完全看不到 gradeTable 和 downLimit 这两个表的内部规则）。
将两者分离，可以使机制(degree)相对保持稳定，而同时支持策略(表)的变化。
Ref: