分层与模块设计：头文件

做“平台”的简单思路：

------------------------------------------------------------------------------------------------------------------------------------

\include

-- config.h //平台配置文件

-- type.h //平台基本类型定义文件

-- api.h //平台接口及数据类型定义

-- all.h //平台对外头文件，包括以上三个文件。这四个文件可以合并成1个或2个。

\level1

-- level1.h  //level1层公用头文件

-- \mod_1a

     -- mod1a.c  //all.h, level1.h, mod1a.h, mod1b.h(if necessary)   

     -- mod1a.h 

-- \mod_1b

    -- mod1b.c //all.h, level1.h, mod1b.h, mod1a.h(if necessary)   

    -- mod1b.h

\level2

-- level2.h  //level2层公用头文件

-- \mod_2a

     -- mod2a.c  //all.h, level1.h,  level2.h, mod2a.h, mod2b.h(if necessary)   

     -- mod2a.h 

-- \mod_2b

    -- mod2b.c //all.h, level1.h,  level2.h, mod2b.h, mod2a.h(if necessary)   

    -- mod2b.h

------------------------------------------------------------------------------------------------------------------------------------

说明：

1、平台通过config.h定制，平台编译宏需满足产品预期（非完全一致）

1）平台基本数据类型是自洽的，通过编译宏规避重复定义的问题。（此时，平台编译宏和产品不一致）

2）平台cpu、os、大小端等类型定义，需和产品保持一致

3）平台规格定义。建议定义为最大规格，而产品规格通过定制参数传递给平台。

2、逻辑上level1调用level2，level1是抽象层，level2是实现层，因此需要引入DIP（依赖倒置）策略，只允许level2调用level1，通过回调函数即可实现。

level1.h的目的有两个：level1层公用头文件，提供给其他层次的头文件。

3、模块间可能存在互相调用接口的情况（应避免引起全局变量），所以可能互相包含对方的头文件。这个时候，要避免形成头文件的依赖。

（有依赖说明模块划分或数据结构设计不合理）。如mod1a.h, mod1b.h不允许存在依赖关系，mod2a.h, mod2b.h同样如此。