C语言的模块化设计和面向对象编程.docx

C语言的模块化设计和面向对象编程分类：C面向对象/C++/Java2011-03-0221:04108人阅读评论（0）收藏举报来自网易杭州研发技术总监“云风”BLOG的几篇面向对象设计的文章C语言对模块化支持的欠缺继续昨天的话题。随便列些以后成书可能会写的东西。既然书的主题是：怎样构建一个（稍具规模的）软件。且我选择用C为实现工具来做这件事情。就不得不谈语言还没有提供给我们的东西。 模块化是最高原则之一（在《Unix编程艺术》一书中，Unix哲学第一条即：模块原则），我们就当考虑如何简洁明快的使用C语言实现模块化。 除开C/C++，在其它现在流行的开发语言中，缺少标准化的模块管理机制是很难想象的。 但这也是C语言本身的设计哲学决定的：把尽可能多的可能性留给程序员。根据实际的系统，实际的需要去定制自己需要的东西。 对于巨型的系统（比如Windows这样的操作系统），一般会考虑使用一种二进制级的模块化方案。由模块自己提供元信息，或是使用统一的管理方案（比如注册表）。稍小一点的系统（我们通常开发接触到的），则会考虑轻量一些的源码级方案。 首先要考虑的往往是模块的依赖关系和初始化过程。 依赖关系可以放由链接器或加载器来解决。尤其在使用C语言时，简单的静态库或动态库，都不太会引起大的麻烦。 C++则不然，C++的某些特性（比如模板类静态成员的构造）必须对早期只供C语言使用的链接器做一些增强。即使是精心编写的C++库，也有可能出现一些意外的bug。这些bug往往需要对编译，链接，加载过程很深刻的理解，才能查出来。注：我并不想以此来反对使用C++做开发。 我们需要着重管理的，是模块的初始化过程。 对于打包在一起的一个库（例如glibc，或是msvcrt），会在加载时有初始化入口，以及卸载时有结束代码。我想说的不是这个，而是我们自己内部拆分的更小的模块的相互依赖关系。 谁先初始化，谁后初始化，这是一个问题。 在C++的语言级解决方案中，使用的是单件模块。要么由链接器决定以怎样的次序来生成初始化代码，这，通常会因为依赖关系和实际构造次序不同而导致bug（注：我在某几本C++书中都见过，待核实。自己好久不写C++也没有实际的错误例子）；要么使用惰性初始化方案。这个惰性初始化也不是万能的，并且有些额外的开销。（多线程环境中尤其需要注意）我使用C语言做初期设计的时候，采用的是一种足够简单的方法。就是，以编码规范来规定，每个模块必须存在一个初始化函数，有规范的名字。比如foo模块的初始化入口叫intfoo_init（）规定：凡使用特定模块，必须调用模块初始化函数。 为了避免模块重复初始化，初始化函数并不直接调用，而是间接的。类似这样： mod_using（foo_init）;mod_using负责调用初始化函数，并保证不重复调用，也可以检查循环依赖。 在这里，我们还约定了初始化成功于否的返回值。（在我们的系统中，返回0表示正确，1表示失败）然后定义了一个宏来做这个使用。 #defineUSING（m）if（mod_using（m##_init,#m））{return1;}注：我个人反对滥用宏。也尽可能的避免它。这里使用宏，经过了慎重的考虑。我希望可以有一个代码扫描器去判断我是否漏掉了模块初始化(可能我使用了一个模块，但忘记初始化它)。宏可以帮助代码扫描分析器更容易实现。而且，使用宏更像是对语言做的轻微且必要的扩展。 这样，我的系统中模块模块的实现代码最后，都有一个init函数，里面只是简单的调用了USING来引用别的模块。例如： #includemodule.h/* 我个人偏爱把module.h的引入放在源文件最后，初始化入口之前。 它里面之定义了USING宏，以及相关管理函数。 这样做是为了避免在代码的其它地方去引入别的模块。 */intfoo_init(){ USING(memory);//引用内存管理模块 USING(log);//引用log模块 return0;}至于模块的卸载，大部分需求下是不需要的。今天在这里就不论证这一点了。 浅谈C语言中模块化设计的范式今天继续谈模块化的问题。这个想慢慢写成个系列，但是不一定连续写。基本是想起来了，就整理点思路出来。主要还是为以后集中整理做点铺垫。 我们都知道，层次分明的代码最容易维护。你可以轻易的换掉某个层次上的某个模块，而不用担心对整个系统造成很大的副作用。 层次不清的设计中，最糟糕的一种是模块循环依赖。即，分不清两个模块谁在上，谁在下。这个时候，最容易牵扯不清，其结果往往是把两者看做一体去维护算了。这里面还涉及一些初始化次序等繁杂的细节。 其次，就是越层的模块联系。当模块A是模块B的上层，而模块B又是模块C的上层，这个时候，让模块C对模块A可见，在模块A中有对C导出接口的直接调用，对于清晰的设计是很