头文件之辩

   前两天整理VC的控件代码，觉得里面有些函数的声明不是很规范，没有很好的模块性，在一个头文件中包含了别的实现文件中的声明，即与某一个实现文件对应的声明，没有存在自己的头文件，而是存在别人的头文件中了，遂就按照这个实践进行整理。

 

 在整理的过程中逐渐地点解了C语言编程，乃至C++编程里面include的组织的“要义”。对于一个模块自身头文件中声明需要引用到头文件，应该声明在自身的头文件中，但实现文件.c或.cpp一般需要引用的文件比自身头文件可能会更多，因为实现文件需要的不仅仅是自己接口的声明，还包含了要实现这些接口实，现体Body需要借用或复用其他模块的接口，而对这些头文件的include，按照当时的顿悟,是不应该在自身的头文件中，而应该在实现文件中进行include。信息是一个逐渐放大过程，纲举目张，在头文件中你见到的只是一个声明或说明，而对于其中实现可能复杂，你不需要可见，也就不需要将这些实现所引用的头文件也放在头文件中，只需要在实现文件中进行include即可。这个声明决定了编译过程给予什么样的地址和空间的安排，在后面再通过链接的过程，将整个源代码生成一个可以执行于某一个平台的程序。感叹，在学校学习时，老师应该将比较低层的东西介绍给学生，而不是只是很粗浅的介绍一个概念，而让学生对这个概念了解不是很透彻。近来常通过维基百科对于一些概念进行深入研究，例如有理数、无理数、代数等，理解了某些基本的东西，就知道这个知识结构里面特征是什么，只所以代数之所为为“代”，呵呵！教育要发展啊。。。。。。。。
 
   按照这样的原则，就粗粗整理了一两个小时，感觉虽然干了一些体力活，但是值得为这点顿悟而付出进一步的劳动，很多时候纸上得来终觉浅，绝知此事要躬行的，在实践中才能领悟的更多。

 

   在整理过程中，遇到了一部分函数的声明出现一些头文件相互包含的场景，才觉得以前的组织方式虽然乱，但至少实现了整个功能的，呵呵！也源于整个代码组织出现问题，但时间太短了，不能进行大的改造，就一部分进行了整理，一部分还按照原来的样子。在一个组织很好的程序里面，很少应该出现反调的情况，绝大多数，应该类似金字塔式，一层层进行支撑，上层需要了解下层，而下层不应该include到上层的东西，不应该出现纠缠，后面再思考这样大的结构吧，先能做多少就做多少，至少会向好的方向发展就可以了，发展本身就是很缓慢的过程，特别是向上的发展，每一步都是不容易，平庸和原地踏步可能是最容易、最省心的！