欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

事件驱动编程、消息驱动编程、数据驱动编程

架构&设计模式 water 8513℃ 0评论
事件驱动
事件驱动机制就是:
让驴拉磨,它不拉,你用鞭抽一下,它就开始拉了。然后又停了,你再抽一下,它又继续拉了
这叫用“鞭”驱动“驴”拉磨

在程序里,程序停止在那不动,你点击一个按钮,它就有反应了,过一会,又没反应了,你再点一下,它又继续运行。
这叫用“事件”驱动“程序”运行
0. 基本概念
  • 窗口/组件

  • 事件

  • 消息(队列)

  • 事件响应(服务处理程序)

  • 调度算法

  • 进程/线程

  • 非阻塞I/O

  • 程序的执行可以看成对CPU,内存,IO资源一次占用

  • 现代操作系统支持多任务,可以分时复用上述资源.

1. 为什么采用事件驱动模型?

事件驱动模型也就是我们常说的观察者,或者发布-订阅模型;理解它的几个关键点:

  • 首先是一种对象间的一对多的关系;最简单的如交通信号灯,信号灯是目标(一方),行人注视着信号灯(多方);

  • 当目标发送改变(发布),观察者(订阅者)就可以接收到改变;

  • 观察者如何处理(如行人如何走,是快走/慢走/不走,目标不会管的),目标无需干涉;所以就松散耦合了它们之间的关系。

2. 代码执行流程

在传统的或“过程化”的应用程序中,应用程序自身控制了执行哪一部分代码和按何种顺序执行代码。从第一行代码执行程序并按应用程序中预定的路径执行,必要时调用过程。
在事件驱动的应用程序中,代码不是按照预定的路径执行-而是在响应不同的事件时执行不同的代码片段。事件可以由用户操作触发、也可以由来自操作系统或其它应用程序调度算法的消息触发、甚至由应用程序本身的消息触发。这些事件的顺序决定了代码执行的顺序,因此应用程序每次运行时所经过的代码的路径都是不同的。

3. 事件驱动模型

在UI编程中,常常要对鼠标点击进行相应,首先如何获得鼠标点击呢?

方式一:创建一个线程,该线程一直循环检测是否有鼠标点击,那么这个方式有以下几个缺点:

  1. CPU资源浪费,可能鼠标点击的频率非常小,但是扫描线程还是会一直循环检测,这会造成很多的CPU资源浪费;如果扫描鼠标点击的接口是阻塞的呢?

  2. 如果是堵塞的,又会出现下面这样的问题,如果我们不但要扫描鼠标点击,还要扫描键盘是否按下,由于扫描鼠标时被堵塞了,那么可能永远不会去扫描键盘;

  3. 如果一个循环需要扫描的设备非常多,这又会引来响应时间的问题;所以,该方式是非常不好的。

方式二:就是事件驱动模型目前大部分的UI编程都是事件驱动模型,如很多UI平台都会提供onClick()事件,这个事件就代表鼠标按下事件。事件驱动模型大体思路如下:

  1. 有一个事件(消息)队列;

  2. 鼠标按下时,往这个队列中增加一个点击事件(消息);

  3. 有个循环,不断从队列取出事件,根据不同的事件,调用不同的函数,如onClick()、onKeyDown()等;

  4. 事件(消息)一般都各自保存各自的处理函数指针,这样,每个消息都有独立的处理函数;如图:

Paste_Image.png

4. 事件驱动处理库
  • select

  • poll

  • epoll

  • libev

事件驱动机制跟消息驱动机制相比


消息驱动


消息驱动和事件驱动很类似,都是先有一个事件,然后产生一个相应的消息,再把消息放入消息队列,由需要的项目获取。他们的区别是消息是谁产生的

消息驱动:鼠标管自己点击不需要和系统有过多的交互,消息由系统(第三方)循环检测,来捕获并放入消息队列。消息对于点击事件来说是被动产生的,高内聚。

事件驱动:鼠标点击产生点击事件后要向系统发送消息“我点击了”的消息,消息是主动产生的。再发送到消息队列中。

事件:按下鼠标,按下键盘,按下游戏手柄,将U盘插入USB接口,都将产生事件。比如说按下鼠标左键,将产生鼠标左键被按下的事件。

消息:当鼠标被按下,产生了鼠标按下事件,windows侦测到这一事件的发生,随即发出鼠标被按下的消息到消息队列中,这消息附带了一系列相关的事件信息,比如鼠标哪个键被按了,在哪个窗口被按的,按下点的坐标是多少?如此等等。

 

1.要理解事件驱动和程序,就需要与非事件驱动的程序进行比较。实际上,现代的程序大多是事件驱动的,比如多线程的程序,肯定是事件驱动的早期则存在许多非事件驱动的程序,这样的程序,在需要等待某个条件触发时,会不断地检查这个条件,直到条件满足,这是很浪费cpu时间的。而事件驱动的程序,则有机会释放cpu从而进入睡眠态(注意是有机会,当然程序也可自行决定不释放cpu),当事件触发时被操作系统唤醒,这样就能更加有效地使用cpu.
2.再说什么是事件驱动的程序。一个典型的事件驱动的程序,就是一个死循环,并以一个线程的形式存在,这个死循环包括两个部分第一个部分是按照一定的条件接收并选择一个要处理的事件,第二个部分就是事件的处理过程。程序的执行过程就是选择事件和处理事件,而当没有任何事件触发时,程序会因查询事件队列失败而进入睡眠状态,从而释放cpu。
3.事件驱动的程序,必定会直接或者间接拥有一个事件队列用于存储未能及时处理的事件
4.事件驱动的程序的行为,完全受外部输入的事件控制,所以,事件驱动的系统中,存在大量这种程序,并以事件作为主要的通信方式。
5.事件驱动的程序,还有一个最大的好处,就是可以按照一定的顺序处理队列中的事件,而这个顺序则是由事件的触发顺序决定的,这一特性往往被用于保证某些过程的原子化。
6.目前windows,linux,nucleus,vxworks都是事件驱动的,只有一些单片机可能是非事件驱动的。


事件模式耦合高,同模块内好用消息模式耦合低,跨模块好用。事件模式集成其它语言比较繁琐,消息模式集成其他语言比较轻松。事件是侵入式设计,霸占你的主循环消息是非侵入式设计,将主循环该怎样设计的自由留给用户。如果你在设计一个东西举棋不定,那么你可以参考win32的GetMessage,本身就是一个藕合度极低的接口,又足够自由,接口任何语言都很方便,具体应用场景再在其基础上封装成事件并不是难事,接口耦合较低,即便哪天事件框架调整,修改外层即可,不会伤经动骨。而如果直接实现成事件,那就完全反过来了。

什么是数据驱动编程

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

转载请注明:学时网 » 事件驱动编程、消息驱动编程、数据驱动编程

喜欢 (11)or分享 (0)

您必须 登录 才能发表评论!