本文示例代码采用的是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上的脚本来描述流程。这一块后面抽时间介绍。
数据驱动编程之表驱动法
最新推荐文章于 2024-05-25 14:51:26 发布