再谈C语言的模块化设计

现代语言为了可以接近玩乐高积木的那样直接组合现有的模块，都对模块化做了语言级别上的支持。我想这一点在软件工程界也是逐步认识到的。C 语言实在是太老了。而它的晚辈 Go 就提供了 import 和 package 两个新的关键字。

这也是我最为认可的方式。之前提到的方案只能说是对其拙劣的模拟。确认语言级的支持，恐怕也只能做到这一步了。

在项目实践中，那个 USING 的方案我用了许多年，还算满意。之前有过更为复杂“精巧”的方法，都被淘汰掉了。为什么？因为每每引入新的概念，都增加了新成员的学习成本。因为几乎每个人都有 C 语言经验，但每个人的项目背景却不同。接受新东西是有成本的。任何不是语言层面上的“必须”，都有值得商榷的地方。总有细节遭到质疑。为什么不这样，或许会更好？这是每个程序员说出或埋在心里的问题。

那个 USING 的方案远不完美，它只是足够简洁，可以让程序员勉强接受而已。但其实还不够简洁。因为从逻辑表达上来说，它是多余的。一个模块使用了另一个模块，代码上已经是自明的。从 C 语言的惯例上来说，只要 #include 了一个相关的 .h 文件，就证明它需要使用关联的模块。

光用宏的技巧很难只依靠一次 #include 就搞定正确的模块初始化次序。因为 C 语言并没有明显的模块概念。如果将每个子模块都编译为动态库可能能一定的解决问题（我曾经试过这种方案），但却会引出别的问题。细粒度的动态库局限性太大。

这两天我结合这半年学习 Go 语言的体验，又仔细考虑了一下这个问题。想到另一个解决方案。

如果我们能规范系统中子模块 API 的命名规范，或许可以借助编译器和相关工具来做一些 meta programming 的工作。

我们可以使用 objdump 来分析编译好的 .o 文件。比如有一个模块 foo ，实现在 foo.c 中。objdump -t 可以得到 .o 中引用以及导出的符号。

我们要求所有子模块中的 C API 都遵守一致的命名规范，假设用驮峰命名的话，foo 模块中的 Api 就看起来像这样 fooApi 。objdump 的结果可以轻易的识别出规范内的引用的其它子模块有哪些。然后生成一个类似之前提到的 USING 方法可以调用的初始化函数。自定义的模块初始化函数可以统一命名为 fooInit 的形式，当这个初始化函数存在，则由自动生成的代码调用一下即可。