原文地址:http://blog.csdn.net/claien/article/details/19287869前言:最近在学习《Unix编程艺术》。以前粗略的翻过,以为是介绍unix工具的。现在认真的看了下,原来是介绍设计原则的。它的核心就是第一章介绍的unix的哲学以及17个设计原则,而后面的内容就是围绕它来展开的。以前说过,要学习适合自己的资料,而判断是否适合的一个方法就是看你是否能够读得下去。我对这本书有一种相见恨晚的感觉。推荐有4~6年工作经验的朋友可以读一下。 正题: 作者在介绍Unix设计原则时,其中有一条为“表示原则:把知识叠入数据以求逻辑质朴而健壮”。结合之前自己的一些经验,我对这个原则很有共鸣,所以先学习了数据驱动编程相关的内容,这里和大家分享出来和大家一起讨论。 数据驱动编程的核心 数据驱动编程的核心出发点是相对于程序逻辑,人类更擅长于处理数据。数据比程序逻辑更容易驾驭,所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。 真的是这样吗?让我们来看一个示例。 假设有一个程序,需要处理其他程序发送的消息,消息类型是字符串,每个消息都需要一个函数进行处理。第一印象,我们可能会这样处理:
上面的消息类型取自sip协议(不完全相同,sip协议借鉴了http协议),消息类型可能还会增加。看着常常的流程可能有点累,检测一下中间某个消息有没有处理也比较费劲,而且,没增加一个消息,就要增加一个流程分支。 按照数据驱动编程的思路,可能会这样设计:
下面这种思路的优势: 1、可读性更强,消息处理流程一目了然。 2、更容易修改,要增加新的消息,只要修改数据即可,不需要修改流程。 3、重用,第一种方案的很多的else if其实只是消息类型和处理函数不同,但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来,而把容易发生变化的部分提到外面。 隐含在背后的思想: 很多设计思路背后的原理其实都是相通的,隐含在数据驱动编程背后的实现思想包括: 1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来,从而达到控制复杂度的目标。 2、隔离变化。像上面的例子,每个消息处理的逻辑是不变的,但是消息可能是变化的,那就把容易变化的消息和不容易变化的逻辑分离。 3、机制和策略的分离。和第二点很像,本书中很多地方提到了机制和策略。上例中,我的理解,机制就是消息的处理逻辑,策略就是不同的消息处理(后面想专门写一篇文章介绍下机制和策略)。 数据驱动编程可以用来做什么: 如上例所示,它可以应用在函数级的设计中。 同时,它也可以应用在程序级的设计中,典型的比如用表驱动法实现一个状态机(后面写篇文章专门介绍)。 也可以用在系统级的设计中,比如DSL(这方面我经验有些欠缺,目前不是非常确定)。 它不是什么: 1、 它不是一个全新的编程模型:它只是一种设计思路,而且历史悠久,在unix/linux社区应用很多; 2、它不同于面向对象设计中的数据:“数据驱动编程中,数据不但表示了某个对象的状态,实际上还定义了程序的流程;OO看重的是封装,而数据驱动编程看重的是编写尽可能少的代码。” 书中的值得思考的话: 数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条,正确的算法就不言自明。编程的核心是数据结构,而不是算法。——Rob Pike 程序员束手无策。。。。。只有跳脱代码,直起腰,仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks 数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。 数据驱动编程之表驱动法
本文示例代码采用的是c语言。 考虑一个消息(事件)驱动的系统,系统的某一模块需要和其他的几个模块进行通信。它收到消息后,需要根据消息的发送方,消息的类型,自身的状态,进行不同的处理。比较常见的一个做法是用三个级联的switch分支实现通过硬编码来实现:
这种方法的缺点: 1、可读性不高:找一个消息的处理部分代码需要跳转多层代码。 2、过多的switch分支,这其实也是一种重复代码。他们都有共同的特性,还可以再进一步进行提炼。 3、可扩展性差:如果为程序增加一种新的模块的状态,这可能要改变所有的消息处理的函数,非常的不方便,而且过程容易出错。 4、程序缺少主心骨:缺少一个能够提纲挈领的主干,程序的主干被淹没在大量的代码逻辑之中。 用表驱动法来实现: 根据定义的三个枚举:模块类型,消息类型,自身模块状态,定义一个函数跳转表:
这种方法的好处: 1、提高了程序的可读性。一个消息如何处理,只要看一下驱动表就知道,非常明显。 2、减少了重复代码。这种方法的代码量肯定比第一种少。为什么?因为它把一些重复的东西:switch分支处理进行了抽象,把其中公共的东西——根据三个元素查找处理方法抽象成了一个函数GetFunFromDriver外加一个驱动表。 3、可扩展性。注意这个函数指针,他的定义其实就是一种契约,类似于java中的接口,c 中的纯虚函数,只有满足这个条件(入参,返回值),才可以作为一个事件的处理函数。这个有一点插件结构的味道,你可以对这些插件进行方便替换,新增,删除,从而改变程序的行为。而这种改变,对事件处理函数的查找又是隔离的(也可以叫做隔离了变化)。、 4、程序有一个明显的主干。 5、降低了复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来,从而达到控制复杂度的目标。 继承与组合 考虑一个事件驱动的模块,这个模块管理很多个用户,每个用户需要处理很多的事件。那么,我们建立的驱动表就不是针对模块了,而是针对用户,应该是用户在某状态下,收到某模块的某事件的处理。我们再假设用户可以分为不同的级别,每个级别对上面的提到的处理又不尽相同。 用面向对象的思路,我们可以考虑设计一个用户的基类,实现相同事件的处理方法;根据级别不同,定义几个不同的子类,继承公共的处理,再分别实现不同的处理。这是最常见的一种思路,可以叫它继承法。 如果用表驱动法怎么实现?直接设计一个用户的类,没有子类,也没有具体的事件的处理方法。它有一个成员,就是一个驱动表,它收到事件后,全部委托给这个驱动表去进行处理。针对用户的级别不同,可以定义多个不同的驱动表来装配不同的对象实例。这个可以叫他组合法。 继承和组合在《设计模式》也有提到。组合的优势在于它的可扩展性,弹性,强调封装性。(继承和组合可以参考这篇文章:面向对象之继承组合浅谈) 至于这种情况下的驱动表,可以继续使用结构体,也可以使用对象。 上面的方法的一点性能优化建议: 如果对性能要求不高,上面的方法足可以应付。如果性能要求很高,可以进行适当的优化。比如,可以建立一个多维数组,每一维分别表示模块,状态,消息。这样,就可以根据这三者的枚举直接根据下标定位到处理函数,而不是查表。(其实还是数据驱动的思想:数据结构是静态的算法。) 数据驱动编程再更高级,更为抽象一点的,应该就是流程脚本或者DSL了。我曾经写过一个简单的寄生在xml上的脚本来描述流程。这一块后面抽时间介绍 根据以往的编程经验,我觉得表驱动的方法十分方便,易于扩展,提高了开发效率,将新需求的编码工作,交给数据格式的定义中。
1. 将逻辑的控制流程等都可以交给数据定义
2. 易于扩展,往往新添加一个数据属性就能解决很多问题,程序的纵向流程,以及其他维度上的分支逻辑,在表驱动中都能横向的属性表示,变换的维度是横向的,而且只有这一个维度。
3.组件思想,表中的每一列都是表的一个子集,组合关系。
4.思维方式的变更,新需求本身的逻辑处理已不再重要,透过具体的逻辑,分离出本质的数据不同,这时会发现,其实很多变更其实已经隐含在已经存在的数据格式中
当你定义了一张表,相当于你拥有了一副扑克,扑克相当于表中每一列,规则是怎样全在于你在每一行添加数据。
缺点:
1. 空间的浪费。 这是最大的缺点
2. 时间的浪费,设计到表中查找已经表遍历的问题,损失效率不大。
|
|
来自: advanced00 > 《c语言》