把这两个概念放在一起，确实不是很工整。但对于热衷设计的我们，只要有用就行。
首先来解释这两个概念。
OO是什么？呵呵,可能大家会笑我，OO谁不知道？不要和我说什么封装/继承/多态！这些都是所谓的特性，我的问题是：OO到底在做什么呢？
我给大家打个比方，假设你是一个项目的项目经理。现在你手头上有一个任务，需要你去完成。你会怎么去做呢？
一个选择，是你自己完成所有任务。当然，如果你愿意夺取你所有的手下的机会的话。你是可以完成。这就是我们以往经常说的面向过程（OP）。你知道所有你该做的，并且你去做了。
当然，你慢慢会发现，你的手下可以帮助你解决一些问题。于是你试图让他们去执行你安排给他们的任务。不过，你并没有脱离OP的阶段，所有的工作都是你在安排，你在策划，你在考虑。你只是使用了一些现成的库来帮助你工作。
随着时间的推移，你的手下开始慢慢能顶替你的工作。你开始将任务直接交给几个手下，告诉他们你想要的结果，让他们放手去干。过程中进行适当的监督和协调。恭喜你，你在采用面向对象了。你不再关心实现任务的具体细节。你关注的是手下工作要开心，调节他的工作状态，适当给些鼓励，适当给些压力，适当给些激励。这就是OO。
是的，OO是处理问题的方式。把你从无所不知的圣人，落地为毫无能力的蠢才。选择OP还是OO，只是你的性格而已。
那么，解释完OO后，我们再来解释一下“事件”这个概念。
什么？事件？不就是函数类型吗？不就是以前Windows下的回掉函数吗？不就是一个特殊类型的指针吗？函数指针。
是的，我的问题同样不是问事件是如何实现的。我是问，事件是做什么的？
在给你做一个比方吧。比方说我们要完成一个任务。内容是从北京到南京，距离1000公里。我们选择的工具是汽车，路线是高速公路。很好，你开始要选择开什么车了。现在市面上有现成的各种品牌的车（这些都是框架提供的现成类，如果用了，你就不需要自己再去实现汽车类了）。你愿意选用吗？可是现在有一个很现实的问题，家用车一般的油箱只有50升，要跑完1000公里，油肯定不够。看来一般的车是满足不了我们的需求了。
一个办法是我们自己造一个车，油箱足够大，能够放120升油。那么显然动力系统就能够满足。不过可想而知，要造一个车可是需要很多专业知识的。这条路你基本走不通，所以你只能又转向原来的方案。
既然一次不够，可不可以加油？当然可以！
好了，这个时候，我们要注意一下，我们在谈论“事件”这个概念，现在才刚刚开始。
对于我们要完成任务的这些人来说，“事件”并不是我们关注。真正关心的人，是那些设计汽车和高速公路的人。
好吧，现在我们要做一个艰难的转变。你由完成任务（从北京到南京）的人，转变为公路系统的总设计师了。等你转变完这个角色变换后，恭喜你，你的设计把控能力又提升了一大步。
假设你已经转换完成。你现在是公路系统总设计师。你在设计道路的同时，当然要解决好我们加油的问题。可是你并不知道我们什么时候需要加油。怎么办呢？
首先必然要在高速公路上设计必要的加油站，然后更重要的是在公路上提出标志，让汽车能够接受到信息，知道什么地方有加油站。
回到软件上来，如果你设计的高速公路类，还有汽车类，那么汽车类应该在接受到高速公路上的加油站信息的时候，就会触发一个事件。至于怎么处理，那就是任务完成者，也就是驾驶员要判断的了。首先看看油还够不够了，如果不够了，就进站加油。
饶了这么大的一圈，我就是想说，事件是框架设计者，让使用者方便扩展或定制自己行为的方式。
我之所以将EOD和OOD这两种方式放在一起讨论，其实也是因为目前的流行框架都是两者的结合。如MFC、VCL、.NET Framework。
最近在讨论Eclipse架构的时候，讨论到它的插件的“扩展点”概念。其实事件也是设计中使用的“扩展点”。或者可以说，EOD是OOD的扩展点。
Event并不是OO本身所特有的。是为了解决“执行流程”问题，在OO的基础上加上的思想。有了这个思想，才让我们这些使用者可以方便实现各种需求。
以往总听到OP和OO的争论，其中心都是理念的争执！其实，真正解决问题的时候，我们经常什么都用！可能那个时候我们才发现，什么思想不思想，能解决问题的就是好的。这也让我们更加相信设计没有边界！
发表于 @ 2006年09月17日 01:51:00|评论(loading...)|编辑