[b]数据驱动编程之表驱动法 本文示例代码采用的是c语言。 [/b]之前介绍过数据驱动编程《[b][url=http://www.1sucai.cn/article/37253.htm]浅谈:什么是数据驱动编程的详解[/url][/b]》。里面介绍了一个简单的数据驱动手法。今天更进一步，介绍一个稍微复杂，更加实用的一点手法——表驱动法。 关于表驱动法，在《unix编程艺术》中有提到，更详细的描述可以看一下《代码大全》，有一章专门进行描述(大概是第八章)。 [b]简单的表驱动： [/b]《[b][url=http://www.1sucai.cn/article/37253.htm]浅谈:什么是数据驱动编程的详解[/url][/b]》中有一个代码示例。它其实也可以看做是一种表驱动手法，只不过这个表相对比较简单，它在收到消息后，根据消息类型确定使用调用什么函数进行处理。 [b]复杂一点的表驱动： [/b]考虑一个消息（事件）驱动的系统，系统的某一模块需要和其他的几个模块进行通信。它收到消息后，需要根据消息的发送方，消息的类型，自身的状态，进行不同的处理。比较常见的一个做法是用三个级联的switch分支实现通过硬编码来实现： [b]这种方法的缺点： [/b]1、可读性不高：找一个消息的处理部分代码需要跳转多层代码。 2、过多的switch分支，这其实也是一种重复代码。他们都有共同的特性，还可以再进一步进行提炼。 3、可扩展性差：如果为程序增加一种新的模块的状态，这可能要改变所有的消息处理的函数，非常的不方便，而且过程容易出错。 4、程序缺少主心骨：缺少一个能够提纲挈领的主干，程序的主干被淹没在大量的代码逻辑之中。 用表驱动法来实现： 根据定义的三个枚举：模块类型，消息类型，自身模块状态，定义一个函数跳转表： [b]这种方法的好处： [/b]1、提高了程序的可读性。一个消息如何处理，只要看一下驱动表就知道，非常明显。 2、减少了重复代码。这种方法的代码量肯定比第一种少。为什么？因为它把一些重复的东西：switch分支处理进行了抽象，把其中公共的东西——根据三个元素查找处理方法抽象成了一个函数GetFunFromDriver外加一个驱动表。 3、可扩展性。注意这个函数指针，他的定义其实就是一种契约，类似于java中的接口，c++中的纯虚函数，只有满足这个条件（入参，返回值），才可以作为一个事件的处理函数。这个有一点插件结构的味道，你可以对这些插件进行方便替换，新增，删除，从而改变程序的行为。而这种改变，对事件处理函数的查找又是隔离的（也可以叫做隔离了变化）。、 4、程序有一个明显的主干。 5、降低了复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。 [b]继承与组合 [/b]考虑一个事件驱动的模块，这个模块管理很多个用户，每个用户需要处理很多的事件。那么，我们建立的驱动表就不是针对模块了，而是针对用户，应该是用户在某状态下，收到某模块的某事件的处理。我们再假设用户可以分为不同的级别，每个级别对上面的提到的处理又不尽相同。 用面向对象的思路，我们可以考虑设计一个用户的基类，实现相同事件的处理方法；根据级别不同，定义几个不同的子类，继承公共的处理，再分别实现不同的处理。这是最常见的一种思路，可以叫它继承法。 如果用表驱动法怎么实现？直接设计一个用户的类，没有子类，也没有具体的事件的处理方法。它有一个成员，就是一个驱动表，它收到事件后，全部委托给这个驱动表去进行处理。针对用户的级别不同，可以定义多个不同的驱动表来装配不同的对象实例。这个可以叫他组合法。 继承和组合在《设计模式》也有提到。组合的优势在于它的可扩展性，弹性，强调封装性。 至于这种情况下的驱动表，可以继续使用结构体，也可以使用对象。 [b]上面的方法的一点性能优化建议： [/b]如果对性能要求不高，上面的方法足可以应付。如果性能要求很高，可以进行适当的优化。比如，可以建立一个多维数组，每一维分别表示模块，状态，消息。这样，就可以根据这三者的枚举直接根据下标定位到处理函数，而不是查表。（其实还是数据驱动的思想：数据结构是静态的算法。） 数据驱动编程再更高级，更为抽象一点的，应该就是流程脚本或者DSL了。我曾经写过一个简单的寄生在xml上的脚本来描述流程。这一块后面抽时间介绍。