文档介绍：模块化编程注意点在谈论今天的主题之前, 先说下我以前的一些经历。在刚开始接触到 C 语言程序的时候, 由于学****内容所限, 写的程序都不是很大, 一般也就几百行而矣。所以所有的程序都完成在一个源文件里面。记得那时候大一参加学校里的一个电子设计大赛, 调试了一个多星期, 所有程序加起来大概将近 1000 行, 长长的一个文件, 从上浏览下来都要好半天。出了错误简单的语法错误还好定位, 其它一些错误, 往往找半天才找的到。那个时候开始知道了模块化编程这个东西, 也尝试着开始把程序分模块编写。最开始是把相同功能的一些函数( 譬如 160 2 液晶的驱动) 全部写在一个头文件(.h) 文件里面,然后需要调用的地方包含进去, 但是很快发现这种方法有其局限性, 很容易犯重复包含的错误。而且调用起来也很不方便。很快暑假的电子设计大赛来临了, 学校对我们的单片机软件编程进行了一些培训。由于学校历年来参加国赛和省赛, 因此积累了一定数量的驱动模块, 那些日子, 老师每天都会布置一定量的任务, 让我们用这些模块组合起来, 完成一定功能。而正是那些日子模块化编程的培训, 使我对于模块化编程有了更进一步的认识。并且程序规范也开始慢慢注意起来。此后的日子, 无论程序的大小, 均采用模块化编程的方式去编写。很长一段时间以来, 一直有单片机爱好者在 QQ 上和我一起交流。有时候,他们会发过来一些有问题的程序源文件,让我帮忙修改一下。同样是长长的一个文件,而且命名极不规范, 从头看下来, 着实是痛苦, 说实话, 还真不如我重新给他们写一个更快一些, 此话到不假, 因为手头积累了一定量的模块, 在完成一个新的系统时候, 只需要根据上层功能需求, 在底层模块的支持下, 可以很快方便的完成。而不需要从头到尾再一砖一瓦的重新编写。藉此, 也可以看出模块化编程的一个好处, 就是可重复利用率高。下面让我们揭开模块化神秘面纱,一窥其真面目。 C 语言源文件*.c 提到 C 语言源文件, 大家都不会陌生。因为我们平常写的程序代码几乎都在这个 文件里面。编译器也是以此文件来进行编译并生成相应的目标文件。作为模块化编程的组成基础, 我们所要实现的所有功能的源代码均在这个文件里。理想的模块化应该可以看成是一个黑盒子。即我们只关心模块提供的功能, 而不管模块内部的实现细节。好比我们买了一部手机, 我们只需要会用手机提供的功能即可, 不需要知晓它是如何把短信发出去的, 如何响应我们按键的输入, 这些过程对我们用户而言,就是是一个黑盒子。在大规模程序开发中, 一个程序由很多个模块组成, 很可能, 这些模块的编写任务被分配到不同的人。而你在编写这个模块的时候很可能就需要利用到别人写好的模块的借口, 这个时候我们关心的是, 它的模块实现了什么样的接口, 我该如何去调用, 至于模块内部是如何组织的, 对于我而言, 无需过多关注。而追求接口的单一性, 把不需要的细节尽可能对外部屏蔽起来,正是我们所需要注意的地方。 C 语言头文件*.h 谈及到模块化编程, 必然会涉及到多文件编译, 也就是工程编译。在这样的一个系统中, 往往会有多个 C 文件, 而且每个 C 文件的作用不尽相同。在我们的 C 文件中, 由于需要对外提供接口, 因此必须有一些函数或者是变量提供给外部其它文件进行调用。假设我们有一个 文