关于头文件的一点事，一点小迷茫，欢迎讨论

[wushichao1987]

设模块A对在A.c中定义了提供给上层软件的借口，在A.h中声明了这些借口供上层软件调用。 由于模块A本身也相当复杂（实际上是驱动软件的接口），所以模块A本身定义了a1.c , a2.c等文件“分拆”一些功能。同时模块B、C等（与A同属于一个“层次”，也是提供驱动软件的功能）有时也要调用a1.c , a2.c等文件中的内容（相对来说很少量，但也有几十个）

背景如上，一点小迷茫就是：

1. A.c中经常有一些只是为了“实现接口”而定义的一些简单的小函数。 如funA提供给上层函数，而fun1不提供给上层借口，只是为了实现funA而定义的，这些接口由于不提供给上层软件调用，所以不能写在A.h文件中，又因为C的先声明后使用的原因导致经常会碰到要“改变函数定义行号”的尴尬问题。针对这个问题也想过要定义在a1.c等文件中，不过总是感觉与a1.c等文件要实现的功能不搭界。同时由于代码多人维护，即使排除老代码的因素，许多同事新增的fun1、fun2等接口也因为“顺手”，“感觉与a1.c等文件不搭界”等原因写在了A.c文件中。这就无法避免有接口使用fun1等函数出现“改变函数定义行号”的尴尬问题（A.c中为了可读性强一些，将a1.c , a2.c等实现的分功能放在了一块，使用了一些特殊的格式，这样一换位置看起来实在是不太舒服）。 针对这个问题我个人感觉是因为A.c文件还是包含了一写“实现”的代码，而不是一个纯的“接口层”，假如A.c简单到只是一个“分发”的接口，可能就不会存在这些问题了。不知道大家有什么好的解决办法。（每当我看到A.c中funA , _funA这样的定义时都感到头疼）
2. 基于1的背景，由于模块B有时要调用a1.c , a2.c中的接口，所以为了方便，将a1.c , a2.c中供模块B、C等调用的接口放在了localA.h中（使用local这个单词是因为大家都是一个层次，驱动层），这样就导致模块B要调用a1.c , a2.c中的接口都要找负责模块A的同事在localA.h文件中声明一下，而且还必须用extern，同时由于代码权限控制的问题，模块B的同事并不知道他“还”可以调用哪些接口。针对这个问题我自己没什么好解法。


有时也想过干脆将a1.h , a2.h直接提供给上层和模块B、C等直接调用得了，不过由于目前系统实在是太庞大，上层软件要求只提供一个A.h文件，所以此想法没法实现，同时由于上下层定义的数据结构不同，上层软件要调用的接口和B、C等模块要调用的借口基本没有重合点，所以也不现实。

针对这个囧境，大家有什么看法，是我们的.h文件组织形式不对还是有什么其他没有注意到得地方呢？

讨论帖，不敢给分了！（其实也没什么分了，哈）

[www_adintr_com]

把各个模块的人都找到一起,先规划一下结构和职责,然后把接口先定义好了再写, 这样就可以减少一部分频繁修改接口的问题.

[AnYidan]

先规划，西方人的办事风格

1。将一个大的工程分为若跟必要的大的模块

2。将每一个较大的模块再细分为较小的模块

3。逐步对每一个较小的模块细分至不能分解

4。从小到大，逐步实现其功能

对应与 C

1. 一个函数干一件事

2。一个模块完成一个功能

3。不需要对外公布的函数不用写入头文件，并在之前加 static

只是个人经验

[就想叫yoko]

a.h只声明给上层用的接口

a.c中只是自己用的函数定义为static

a.c中供b.c c.c使用的函数只在a.c中声明定义, 声明不放在a.h中
b.c c.c中extern它们

不过话说回来
第二种和第三种函数应该尽量少啊
尤其是第三种

[wushichao1987]

我实话是说，求人不如求己，蛋疼