[转]什么是数据驱动编程

http://www.cnblogs.com/chgaowei/archive/2011/08/03/2126724.html

前言:

最近在学习《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编程艺术》作者。

时间: 2024-10-05 05:32:19

[转]什么是数据驱动编程的相关文章

【转】 数据驱动编程之表驱动法

http://blog.csdn.net/chgaowei/article/details/6966857 本文示例代码采用的是c语言.之前介绍过数据驱动编程<什么是数据驱动编程>.里面介绍了一个简单的数据驱动手法.今天更进一步,介绍一个稍微复杂,更加实用的一点手法——表驱动法.关于表驱动法,在<unix编程艺术>中有提到,更详细的描述可以看一下<代码大全>,有一章专门进行描述(大概是第八章). 简单的表驱动:<什么是数据驱动编程>中有一个代码示例.它其实也

第十三章 异步和数据驱动编程

第十三章异步和数据驱动编程 本章介绍 ■异步工作流编程 ■使用 F# Interactive 浏览数据 ■使用度量单位定义类型 ■处理与可视化数据 我们首先引述了一次对比尔 · 盖茨的采访,他谈到他感兴趣的编程任务的类型,并描述了编写应用程序的典型情况: 从 web 获取数据,不只是考虑把它当作文本,而且要引入结构,然后- -,尝试不同的数据表现方式,且以交互的方式.- 写很少的代码,可以有自己专门的算法来处理数据.[2008年,盖茨] 这正好说出了我们在这一章所要做的,我们将会看到,F# 语言

数据驱动与数据抽象

1.数据驱动 考虑这样一个场景: 我们同时需要从buffer1.buffer2.buffer3中分别取出数据,并应用任意的逻辑计算得到一个Result,我们要怎么做? ①不经过大脑的话,应该是这样 { if(is buffer1) access(buffer1) if(is_buffer2) access(buffer2) ... } 这样的逻辑的确可以解决当前问题,然而某一天早上突然被告知需要buffer4.buffer5这样的东西,就只能继续和if else较劲. ②再来看下面一种解法 co

第四部分 函数式编程应用

虽然函数式编程肯定是优雅的,但是,你可能更感兴趣的是其实用目的:作为一种通用的风格,是有用的,在某些问题域中,它肯定更出色.我们已经看到的例子,比如,第四章绘制饼图的应用程序,和第十一章简单的照片浏览器,这些示例的主要目的,是为了演示特定的概念和技术. 第四部分则不同.在每一章,我们将花大量时间讨论实际问题,使用最适当的 F# 特点和函数式编程来解决.这些代码将使用我们到目前为止学到的多种功能,限制在一章中讨论,会比较复杂. 函数式编程在两个领域有明显优点:异步(asynchronous)和并行

d3可视化实战02:理解d3数据驱动的真正含义

前文中已经提到,SVG从诞生之初起就可以非常方便地使用javascript脚本语言来进行其DOM对象的控制.当然,控制的方法有很多,有直接控制SVG对象的方法,例如使用原生js:有帮你封装一下图形接口再进行直接控制的js类库,如 Raphaël.但是正如我在第一篇文章中所说,d3作为一个中间型类库还能脱颖而出的重要原因,在于它突破了其他类库的那种直接控制表现层的机制,而采用了对于web图形处理领域较为新颖的数据驱动机制(2011),并获得了极大的成功. 数据驱动的历史 数据驱动编程并不是一个新鲜

数据驱动编程法

转载至:http://blog.csdn.net/chgaowei/article/details/6658260 什么是数据驱动编程 前言: 最近在学习<Unix编程艺术>.以前粗略的翻过,以为是介绍unix工具的.现在认真的看了下,原来是介绍设计原则的.它的核心就是第一章介绍的unix的哲学以及17个设计原则,而后面的内容就是围绕它来展开的.以前说过,要学习适合自己的资料,而判断是否适合的一个方法就是看你是否能够读得下去.我对这本书有一种相见恨晚的感觉.推荐有4~6年工作经验的朋友可以读一

深入分析面向对象中的对象概念(转)

OOP:面向对象编程,一提到面向对象,大家可能就想到类,接口.一说特性,大家可能张口就来:继承.封装.多态,那么到底什么样的对象(类)才是真正意义上的对象呢?特别是现在流行的DDD领域驱动设计思想,讲究职责划分,那么如何定义一个对象(类)它应该具有的一些特性.行为方法及承担责任成为关键. 一个看似简单的问题,其实也是耐人思索,之前也在网上看到一些人关于讨论类的设计问题,认为设计类时不应该考虑数据库,我觉得这只是实现真正的面向对象设计的基础,也是前提条件,大多数程序员之前都是受面向过程编程思想的影

简单的XML读取器

XML 指可扩展标记语言(EXtensible Markup Language) (有个很明显的槽点),是一种主要设计用来数据传输存储的语言. 有关语法规则我是参考了这个链接. http://www.w3school.com.cn/xml/xml_syntax.asp 看 gcc4 的时候觉得数据驱动编程很酷,于是顺带觉得xml很酷,正好暑假闲就写了个xml读取器看看,鼓捣了几天,弄好了大致上的功能,这里所说大致上,是能够满足检查语法错误并给出错误信息到标准输出设备(不保证报错信息绝对有用).如

面向对象的概念详解(转)

OOP:面向对象编程,一提到面向对象,大家可能就想到类,接口.一说特性,大家可能张口就来:继承.封装.多态,那么到底什么样的对象(类)才是真正意义上的对象呢?特别是现在流行的DDD领域驱动设计思想,讲究职责划分,那么如何定义一个对象(类)它应该具有的一些特性.行为方法及承担责任成为关键. 一个看似简单的问题,其实也是耐人思索,之前也在网上看到一些人关于讨论类的设计问题,认为设计类时不应该考虑数据库,我觉得这只是实现真正的面向对象设计的基础,也是前提条件,大多数程序员之前都是受面向过程编程思想的影