数据驱动

数据驱动编程之表驱动法

前言：

最近在学习《Unix编程艺术》。以前粗略的翻过，以为是介绍unix工具的。现在认真的看了下，原来是介绍设计原则的。它的核心就是第一章介绍的unix的哲学以及17个设计原则，而后面的内容就是围绕它来展开的。以前说过，要学习适合自己的资料，而判断是否适合的一个方法就是看你是否能够读得下去。我对这本书有一种相见恨晚的感觉。推荐有4~6年工作经验的朋友可以读一下。

正题：

作者在介绍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编程艺术》作者。

数据驱动编程之表驱动法

本文示例代码采用的是c语言。
之前介绍过数据驱动编程《什么是数据驱动编程》。里面介绍了一个简单的数据驱动手法。今天更进一步，介绍一个稍微复杂，更加实用的一点手法——表驱动法。
关于表驱动法，在《unix编程艺术》中有提到，更详细的描述可以看一下《代码大全》，有一章专门进行描述(大概是第八章)。

简单的表驱动：
《什么是数据驱动编程》中有一个代码示例。它其实也可以看做是一种表驱动手法，只不过这个表相对比较简单，它在收到消息后，根据消息类型确定使用调用什么函数进行处理。

复杂一点的表驱动：

考虑一个消息（事件）驱动的系统，系统的某一模块需要和其他的几个模块进行通信。它收到消息后，需要根据消息的发送方，消息的类型，自身的状态，进行不同的处理。比较常见的一个做法是用三个级联的switch分支实现通过硬编码来实现：

switch(sendMode)  {      case:  }  switch(msgEvent)  {      case:  }  switch(myStatus)  {      case:  }  

这种方法的缺点：
1、可读性不高：找一个消息的处理部分代码需要跳转多层代码。
2、过多的switch分支，这其实也是一种重复代码。他们都有共同的特性，还可以再进一步进行提炼。
3、可扩展性差：如果为程序增加一种新的模块的状态，这可能要改变所有的消息处理的函数，非常的不方便，而且过程容易出错。
4、程序缺少主心骨：缺少一个能够提纲挈领的主干，程序的主干被淹没在大量的代码逻辑之中。

用表驱动法来实现：
根据定义的三个枚举：模块类型，消息类型，自身模块状态，定义一个函数跳转表：

typedef struct  __EVENT_DRIVE  {      MODE_TYPE mod;//消息的发送模块      EVENT_TYPE event;//消息类型      STATUS_TYPE status;//自身状态      EVENT_FUN eventfun;//此状态下的处理函数指针  }EVENT_DRIVE;    EVENT_DRIVE eventdriver[] = //这就是一张表的定义，不一定是数据库中的表。也可以使自己定义的一个结构体数组。  {      {MODE_A, EVENT_a, STATUS_1, fun1}      {MODE_A, EVENT_a, STATUS_2, fun2}      {MODE_A, EVENT_a, STATUS_3, fun3}      {MODE_A, EVENT_b, STATUS_1, fun4}      {MODE_A, EVENT_b, STATUS_2, fun5}            {MODE_B, EVENT_a, STATUS_1, fun6}      {MODE_B, EVENT_a, STATUS_2, fun7}      {MODE_B, EVENT_a, STATUS_3, fun8}      {MODE_B, EVENT_b, STATUS_1, fun9}      {MODE_B, EVENT_b, STATUS_2, fun10}  };    int driversize = sizeof(eventdriver) / sizeof(EVENT_DRIVE)//驱动表的大小    EVENT_FUN GetFunFromDriver(MODE_TYPE mod, EVENT_TYPE event, STATUS_TYPE status)//驱动表查找函数  {      int i = 0;      for (i = 0; i < driversize; i ++)      {          if ((eventdriver[i].mod == mod) && (eventdriver[i].event == event) && (eventdriver[i].status == status))          {              return eventdriver[i].eventfun;          }      }      return NULL;  }  

这种方法的好处：
1、提高了程序的可读性。一个消息如何处理，只要看一下驱动表就知道，非常明显。
2、减少了重复代码。这种方法的代码量肯定比第一种少。为什么？因为它把一些重复的东西：switch分支处理进行了抽象，把其中公共的东西——根据三个元素查找处理方法抽象成了一个函数GetFunFromDriver外加一个驱动表。
3、可扩展性。注意这个函数指针，他的定义其实就是一种契约，类似于java中的接口，c++中的纯虚函数，只有满足这个条件（入参，返回值），才可以作为一个事件的处理函数。这个有一点插件结构的味道，你可以对这些插件进行方便替换，新增，删除，从而改变程序的行为。而这种改变，对事件处理函数的查找又是隔离的（也可以叫做隔离了变化）。、
4、程序有一个明显的主干。
5、降低了复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

继承与组合
考虑一个事件驱动的模块，这个模块管理很多个用户，每个用户需要处理很多的事件。那么，我们建立的驱动表就不是针对模块了，而是针对用户，应该是用户在某状态下，收到某模块的某事件的处理。我们再假设用户可以分为不同的级别，每个级别对上面的提到的处理又不尽相同。
用面向对象的思路，我们可以考虑设计一个用户的基类，实现相同事件的处理方法；根据级别不同，定义几个不同的子类，继承公共的处理，再分别实现不同的处理。这是最常见的一种思路，可以叫它继承法。
如果用表驱动法怎么实现？直接设计一个用户的类，没有子类，也没有具体的事件的处理方法。它有一个成员，就是一个驱动表，它收到事件后，全部委托给这个驱动表去进行处理。针对用户的级别不同，可以定义多个不同的驱动表来装配不同的对象实例。这个可以叫他组合法。
继承和组合在《设计模式》也有提到。组合的优势在于它的可扩展性，弹性，强调封装性。（继承和组合可以参考这篇文章：面向对象之继承组合浅谈）
至于这种情况下的驱动表，可以继续使用结构体，也可以使用对象。

上面的方法的一点性能优化建议：
如果对性能要求不高，上面的方法足可以应付。如果性能要求很高，可以进行适当的优化。比如，可以建立一个多维数组，每一维分别表示模块，状态，消息。这样，就可以根据这三者的枚举直接根据下标定位到处理函数，而不是查表。（其实还是数据驱动的思想：数据结构是静态的算法。）

数据驱动编程再更高级，更为抽象一点的，应该就是流程脚本或者DSL了。我曾经写过一个简单的寄生在xml上的脚本来描述流程。这一块后面抽时间介绍

转自：http://www.cnblogs.com/chgaowei/archive/2011/11/14/2248920.html

根据以往的编程经验，我觉得表驱动的方法十分方便，易于扩展，提高了开发效率，将新需求的编码工作，交给数据格式的定义中。

1. 将逻辑的控制流程等都可以交给数据定义

2. 易于扩展，往往新添加一个数据属性就能解决很多问题，程序的纵向流程，以及其他维度上的分支逻辑，在表驱动中都能横向的属性表示，变换的维度是横向的，而且只有这一个维度。

3.组件思想，表中的每一列都是表的一个子集，组合关系。

4.思维方式的变更，新需求本身的逻辑处理已不再重要，透过具体的逻辑，分离出本质的数据不同，这时会发现，其实很多变更其实已经隐含在已经存在的数据格式中

当你定义了一张表，相当于你拥有了一副扑克，扑克相当于表中每一列，规则是怎样全在于你在每一行添加数据。

缺点： 1. 空间的浪费。 这是最大的缺点

2. 时间的浪费，设计到表中查找已经表遍历的问题，损失效率不大。