C语言表驱动法编程实践

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

——Rob Pike 

说明

     本文基于这样的认识：数据是易变的，逻辑是稳定的。

     本文例举的编程实现多为代码片段，但不影响描述的完整性。

     本文例举的编程虽然基于C语言，但其编程思想也适用于其他语言。

     此外，本文不涉及语言相关的运行效率讨论。

1 概念提出

     所谓表驱动法(Table-Driven Approach)简而言之就是用查表的方法获取数据。此处的“表”通常为数组，但可视为数据库的一种体现。

     根据字典中的部首检字表查找读音未知的汉字就是典型的表驱动法，即以每个字的字形为依据，计算出一个索引值，并映射到对应的页数。相比一页一页地顺序翻字典查字，部首检字法效率极高。

     具体到编程方面，在数据不多时可用逻辑判断语句(if…else或switch…case)来获取值；但随着数据的增多，逻辑语句会越来越长，此时表驱动法的优势就开始显现。

     例如，用36进制(A表示10，B表示11，…)表示更大的数字，逻辑判断语句如下：

     当然也可以用switch…case结构，但实现都很冗长。而用表驱动法(将numChar存入数组)则非常直观和简洁。如：

     像这样直接将变量当作下数组下标来读取数值的方法就是直接查表法。

     注意，如果熟悉字符串操作，则上述写法可以更简洁：

     使用表驱动法时需要关注两个问题：一是如何查表，从表中读取正确的数据；二是表里存放什么，如数值或函数指针。前者参见1.1节“查表方式”内容，后者参见1.2节“实战示例”内容。

1.1 查表方式

     常用的查表方式有直接查找、索引查找和分段查找等。

1.1.1 直接查找

     即直接通过数组下标获取到数据。如果熟悉哈希表的话，可以很容易看出这种查表方式就是哈希表的直接访问法。

     如获取星期名称，逻辑判断语句如下：

     而实现同样的功能，可将这些数据存储到一个表里：

     类似哈希表特性，表驱动法适用于无需有序遍历数据，且数据量大小可提前预测的情况。

     对于过于复杂和庞大的判断，可将数据存为文件，需要时加载文件初始化数组，从而在不修改程序的情况下调整里面的数值。

     有时，访问之前需要先进行一次键值转换。如表驱动法表示端口忙闲时，需将槽位端口号映射为全局编号。所生成的端口数目大小的数组，其下标对应全局端口编号，元素值表示相应端口的忙闲状态。

1.1.2 索引查找

     有时通过一次键值转换，依然无法把数据(如英文单词等)转为键值。此时可将转换的对应关系写到一个索引表里，即索引访问。

 如现有100件商品，4位编号，范围从0000到9999。此时只需要申请一个长度为100的数组，且对应2位键值。但将4位的编号转换为2位的键值，可能过于复杂或没有规律，最合适的方法是建立一个保存该转换关系的索引表。采用索引访问既节省内存，又方便维护。比如索引A表示通过名称访问，索引B表示通过编号访问。

1.1.3 分段查找

 通过确定数据所处的范围确定分类(下标)。有的数据可分成若干区间，即具有阶梯性，如分数等级。此时可将每个区间的上限(或下限)存到一个表中，将对应的值存到另一表中，通过第一个表确定所处的区段，再由区段下标在第二个表里读取相应数值。注意要留意端点，可用二分法查找，另外可考虑通过索引方法来代替。

     如根据分数查绩效等级：

     上述两张表(数组)也可合并为一张表(结构体数组)，如下所示：

     该表结构已具备的数据库的雏形，并可扩展支持更为复杂的数据。其查表方式通常为索引查找，偶尔也为分段查找；当索引具有规律性(如连续整数)时，退化为直接查找。

     使用分段查找法时应注意边界，将每一分段范围的上界值都考虑在内。找出所有不在最高一级范围内的值，然后把剩下的值全部归入最高一级中。有时需要人为地为最高一级范围添加一个上界。

     同时应小心不要错误地用“<”来代替“<=”。要保证循环在找出属于最高一级范围内的值后恰当地结束，同时也要保证恰当处理范围边界。

1.2 实战示例

    本节多数示例取自实际项目。表形式为一维数组、二维数组和结构体数组；表内容有数据、字符串和函数指针。基于表驱动的思想，表形式和表内容可衍生出丰富的组合。

1.2.1 字符统计

     问题：统计用户输入的一串数字中每个数字出现的次数。

     普通解法主体代码如下：

     这种解法的缺点显而易见，既不美观也不灵活。其问题关键在于未将数字字符与数组aDigitCharNum下标直接关联起来。

     以下示出更简洁的实现方式：

     上述实现考虑到0也为数字字符。该解法也可扩展至统计所有ASCII可见字符。

1.2.2 月天校验

     问题：对给定年份和月份的天数进行校验(需区分平年和闰年)。

     普通解法主体代码如下：

     以下示出更简洁的实现方式：

1.2.3 名称构造

     问题：根据WAN接口承载的业务类型(Bitmap)构造业务类型名称字符串。

     普通解法主体代码如下：

     以下示出C语言中更简洁的实现方式：

     新的实现将数据和逻辑分离，维护起来非常方便。只要逻辑(规则)不变，则唯一可能的改动就是数据(paSvrNames)。

1.2.4 值名解析

     问题：根据枚举变量取值输出其对应的字符串，如PORT_FE(1)输出“Fe”。

     以下给出NameParser的简单应用示例：

     gUniNameMap在实际项目中有十余个条目，若采用逻辑链实现将非常冗长。

1.2.5 取值映射

     问题：不同模块间同一参数枚举值取值可能有所差异，需要适配。

     此处不再给出普通的switch…case或if…else if…else结构，而直接示出以下表驱动实现：

     相应地，从loopMIBState映射到loopMEState需要定义一个ConvertLoopMIBStateToMEState函数。更进一步，所有类似的一对一映射关系都必须如上的映射(转换)函数，相当繁琐。

     事实上，从抽象层面看，该映射关系非常简单。提取共性后定义带参数宏，如下所示：

    参数取值转换时直接调用统一的映射器宏，如下：

     另举一例：

1.2.6 版本控制

 问题：控制OLT与ONU之间的版本协商。ONU本地设置三比特控制字，其中bit2(MSB)~bit0(LSB)分别对应0x21、0x30和0xAA版本号；且bitX为0表示上报对应版本号，bitX为1表示不上报对应版本号。其他版本号如0x20、0x13和0x1必须上报，即不受控制。

     最初的实现采用if…else if…else结构，代码非常冗长，如下：

    以下示出C语言中更简洁的实现方式(基于二维数组)：

1.2.7 消息处理

     问题：终端输入不同的打印命令，调用相应的打印函数，以控制不同级别的打印。

     这是一段消息(事件)驱动程序。本模块接收其他模块(如串口驱动)发送的消息，根据消息中的打印级别字符串和开关模式，调用不同函数进行处理。常见的实现方法如下：

     以下示出C语言中更简洁的实现方式：

     这种表驱动消息处理实现的优点如下：

增强可读性，消息如何处理从表中一目了然。

增强可扩展性。更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。

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

主干清晰，代码重用。

     若各索引为顺序枚举值，则建立多维数组(每维对应一个索引)，根据下标直接定位到处理函数，效率会更高。

     注意，考虑到本节实例中logOam/logPon或nologOam/nologPon等函数本质上是基于打印级别的比特操作，因此可进一步简化。以下例举其相似实现：

1.2.8 掩码表

参见《采用掩码方式简化产品国家地区支持能力的表示》一文。

该例实现中用到消息、掩码、函数指针等概念。

2 编程思想

     表驱动法属于数据驱动编程的一种，其核心思想在《Unix编程艺术》和《代码大全2》中均有阐述。两者均认为人类阅读复杂数据结构远比复杂的控制流程容易，即相对于程序逻辑，人类更擅长于处理数据。

     本节将由Unix设计原则中的“分离原则”和“表示原则”展开。

分离原则：策略同机制分离，接口同引擎分离

     机制即提供的功能；策略即如何使用功能。

     策略的变化要远远快于机制的变化。将两者分离，可以使机制相对保持稳定，而同时支持策略的变化。

     代码大全中提到“隔离变化”的概念，以及设计模式中提到的将易变化的部分和不易变化的部分分离也是这个思路。

表示原则：把知识叠入数据以求逻辑质朴而健壮

     即使最简单的程序逻辑让人类来验证也很困难，但就算是很复杂的数据，对人类来说，还是相对容易推导和建模的。数据比编程逻辑更容易驾驭。在复杂数据和复杂代码中选择，宁可选择前者。更进一步，在设计中，应该主动将代码的复杂度转移到数据中去(参考“版本控制”)。

     在“消息处理”示例中，每个消息处理的逻辑不变，但消息可能是变化的。将容易变化的消息和不容易变化的查找逻辑分离，即“隔离变化”。此外，该例也体现消息内部的处理逻辑(机制)和不同的消息处理(策略)分离。

     数据驱动编程可以应用于：

函数级设计，如本文示例。

程序级设计，如用表驱动法实现状态机。

系统级设计，如DSL。

     注意，数据驱动编程不是全新的编程模型，只是一种设计思路，在Unix/Linux开源社区应用很多。数据驱动编程中，数据不但表示某个对象的状态，实际上还定义程序的流程，这点不同于面向对象设计中的数据“封装”。

3 附录

3.1 网友观点

     (以下观点摘自博客园网友“七心葵”的回帖，非常具有启发性。)

     Booch的《面向对象分析与设计》一书中，提到所有的程序设计语言大概有3个源流：结构化编程；面向对象编程；数据驱动编程。

     我认为数据驱动编程的本质是“参数化抽象”的思想，不同于OO的“规范化抽象”的思想。

     数据驱动编程在网络游戏开发过程中很常用，但是少有人专门提到这个词。

     数据驱动编程有很多名字：元编程，解释器/虚拟机，LOP/微语言/DSL等。包括声明式编程、标记语言、甚至所见即所得的拖放控件，都算是数据驱动编程的一种吧。

     数据驱动编程可以帮助处理复杂性，和结构化编程、OO 均可相容。(正交的角度)

     将变和不变的部分分离，策略和机制分离，由此联想到的还有：(数据和代码的分离，微语言和解释器的分离，被生成代码和代码生成器的分离)；更近一步：(微内核插件式体系结构) 

 元编程应该说是更加泛化的数据驱动编程，元编程不是新加入一个间接层，而是退居一步，使得当前的层变成一个间接层。元编程分为静态元编程(编译时)和动态元编程(运行时)，静态元编程本质上是一种

代码生成技术或者编译器技术；动态元编程一般通过解释器(或虚拟机)加以实现。

 数据驱动编程当然也不应该说是“反抽象的”，但的确与“OO抽象”的思维方式是迥然不同，泾渭分明的，如TAOUP一书中所述：“在Unix的模块化传统和围绕OO语言发展起来的使用模式之间，存在着紧张的对立关系”应该说数据驱动编程的思路与结构化编程和OO是正交的，更类似一种“跳出三界外，不在五行中”的做法。

     编程和人的关系

     人类心智的限制，一切的背后都有人的因素作为依据：

     a 人同时关注的信息数量：7+-2 (所以要分模块)

     b 人接收一组新信息的平均时间5s (所以要简单，系统总的模块数不要太多)

     c 人思维的直观性(人的视觉能力和模糊思维能力)，这意味这两点：

     A “直”——更善于思考自己能直接接触把玩的东西；(所以要“浅平透”、使用具象的设计，要尽量代码中只有顺直的流程)，

     B “观”——更善于观图而不是推算逻辑；(所以要表驱动法，数据驱动编程，要UML，要可视化编程——当然MDA是太理想化了)

     d 人不能持续集中注意力(人在一定的代码行数中产生的bug数量的比例是一定的，所以语言有具有表现力，要体现表达的经济性)

     所以要机制与策略分离，要数据和代码分离(数据驱动编程)，要微语言，要DSL，要LOP……

     e 人是有创造欲，有现实利益心的(只要偶可能总是不够遵从规范，或想创造规范谋利——只要成本能承受，在硬件领域就不行)

     另外，开一个有意思的玩笑，Unix编程艺术艺术的英文缩写为TAOUP，我觉得可以理解为UP之TAO——向上抛出之道——将复杂的易变的逻辑作为数据或更高层代码抛给上层！

3.2 函数指针

     “消息处理”一节示例中的函数指针有点插件结构的味道。可对这些插件进行方便替换，新增，删除，从而改变程序的行为。而这种改变，对事件处理函数的查找又是隔离的(隔离变化)。

     函数指针非常有用，但使用时需注意其缺陷：无法检查参数(parameter)和返回值(return value)的类型。因为函数已经退化成指针，而指针不携带这些类型信息。缺少类型检查，当参数或返回值不一致时，可能会造成严重的错误。

     例如，定义三个函数，分别具有两个参数：

     int max(int x, int y)  {  return x>y?x:y;  }

     int min(int x, int y)  {  return x

     int add(int x, int y)  {  return x+y;  }

     而处理函数却定义为：

     int process(int x, int y, int (*f)())  {  return (*f)(x, y);  }

 其中，第三个参数是一个没有参数且返回int型变量的函数指针。但后面却用process(a,b,max)的方式进行调用，max带有两个参数。若编译器未检查出错误，而又不小心将return

(*f)(x,y);写成return (*f)(x);，那么后果可能很严重。

     因此在C语言中使用函数指针时，一定要小心"类型陷阱"。