结构化设计的救命稻草-回调机制

类别:VC语言 点击:0 评论:0 推荐:

摘要:开发模式的确立是软件开发过程中不可缺少的一部分,就目前来说,面向过程和面向对象是两种主要的设计方法,虽然面向对象OOP是比较流行的字眼,但不表示面向过程就一定好无作为,毕竟面向过程设计方法也有适合其应用的软件系统:以功能操作为主,扩展性要求不高,无需过多考虑复用以及软件的通用性能。那是不是面向过程的设计方法对于诸如系统框架扩展问题就丝毫没有办法了呢?

按照面向过程的基本原则,划分系统功能模块、模块细分到函数、生成系统整体的结构模型,似乎在整个过程中没有任何东西可以用来提供系统扩展,其实解决的方法还是有的,这根救命稻草就是回调机制。

一谈到回调机制,当然就少不了我们的主角:系统API(通常都是)和回调函数,这两者缺一不可。其实回调的基本思想就是由系统给我们提供一些接口,也就是常使用的API,这种函数可以将某个其他函数的地址作为其参数之一,而且可以利用该地址对这个函数进行调用,而被调用的函数就是我们通常所说的回调函数了。
下面给个回调函数使用的小例子:
------------------------------------------
//相当于我们提到的系统API
mainFunc( void*  userFunc )//当然参数不会这么简单,只是模拟
{
 while (...)
 {
  printf("ok!");
                //调用回调函数了
  if (userFunc!=NULL) 
   userFunc();
 }
}
可以看出MainFunc可以根据函数userFunc的地址调用它。
------------------------------------------
这样使用者只需要定义一个函数:void myFunc(),然后按照mainFunc(&myFunc)(&只表示传递的是函数的地址,无具体含义),就可以让我们的mainFunc来调用myFunc从而实现相应的功能,这样当然可以完成我们预期的目的-扩展现有系统。

在windows系统中,支持这种回调机制的系统API不占少数,像实现ListControl排序的SortItem()函数,还有操作Font使用的函数EnumFontFamilies()都有提供这种回调机制,使得我们的用户有机会添加自己期望的功能实现。当然,使用回调函数并不是一个轻松的事情,如果我们的系统中存在了大量的回调函数是很难管理的,这个就与系统中存在大量全局变量一样,出现多个函数争相访问同一个变量我们就很难使用简单的逻辑来处理,容易陷入混乱,因此,尽管回调机制可以在某种程度上达到我们的目的,但切不可乱加使用,不然后果很难预料。

当然至于详细的回调函数实现,还需要大家潜心研究,这里我只是总结一下:
1 回调函数是由开发者按照一定的原型进行定义的函数(每个回调函数都必须遵循这个原型来设计)

例如:
------------------------------------------
BOOL CALLBACK DialogProc(
    
     HWND hwndDlg, // handle of dialog box
     UINT uMsg, // message
     WPARAM wParam, // first message parameter
     LPARAM lParam // second message parameter
     );
------------------------------------------
说明:
回调函数必须有关键词 CALLBACK
回调函数本身必须是全局函数或者静态函数,不可定义为某个特定的类的成员函数

2 回调函数并不由开发者直接调用执行(只是使用系统接口API函数作为起点)
3 回调函数通常作为参数传递给系统API,由该API来调用
4 回调函数可能被系统API调用一次,也可能被循环调用多次(SortItem就是自调用)

最后说句题外话,其实windows系统中还有另一种机制-消息机制,也是一个比较不错的工具,能够为很多实际的问题提供解决方法,这个以后再总结了。

                                                                                                                   --Kingle--

本文地址:http://com.8s8s.com/it/it297.htm