以前我转载过，现在找不到了，从新开篇博客吧。我们一直在写代码，大部分人都是从底层往上学（只有一些极少数的幸运儿能够有幸从上往下学习），因此我们没有机会站在工程的角度或者说产品的角度来看待我们的代码。通俗的说，就是我们只对自己的一亩三分地熟悉，而没有全局观。没有全局观，不能站在工程的角度看待问题，也就无所谓封装了。这篇文章就是封装的入门知识，让我们从另外一个高度来看待问题，思考问题。希望能够帮助大家。。。。。。
废话这么多，进入正文：
我们统一管模块不叫模块，而叫service。
一个service一定是保存在一个文件夹里面的；service叫什么名字，文件夹就叫什么名字。
一个service对外界来说就是一个黑盒子。黑盒子的意思就是说，外界对于service的内部，也就是文件夹里面的内容是不关心的；黑盒子与外界理论上只通过接口进行沟通。
因此，一个service的文件夹里面，一定有一个与service同名的.h文件，我们叫做接口头文件。外界要想使用这个service，只能通过包含这个头文件来实现。
比如，我们有一个service叫做byte_queue；那么文件夹的名字也叫作byte_queue；在这个文件夹里面就有一个 byte_queue.h。
这里，接口头文件是用来从service内部向外部提供接口的。从提供信息的角度来说是由内而外的。因此我们一般认为，接口头文件是用来“输出接口”的。
与之相对的，对一个service来说，往往还是要提供一些输入信息的。比如，系统的配置（通过宏来配置代码）；系统的基础环境（变量类型之类的）；还有这个service可能会依赖的其他service；这类信息是由外而内的输入信息的。我们用一个配置型头文件 app_cfg.h 来承担这个责任。
大家基本上都遇到过一个系统里面只有顶层有一个system.h；然后所有.c都包含system.h来获得便利的模式。即便你以前没有遇到过，以后也一定会遇到——这就是比较传统的处理头文件的做法。
这种做法混合了前面所说的两种头文件的职能——正因为是混合了，所以才导致了很多混乱：
首先，这种混合做法根本没有模块化的思想。
其次，将输入和输出信息混合在一起，容易造成复杂的包含性错误。
所以应该区分信息的类型，然后放置到正确的头文件中。
比如，晶体配置，硬件连接，明显属于配置类或者基础环境类的信息。这些信息应该是输入性质的，应该写入配制头文件。
一个service里面必然拥有一个接口头文件；也必然拥有一个配制头文件。
接口头文件的名字和service名称一样；但配制头文件一定叫app_cfg.h(为啥一定呢？因为是前辈们规定的)
模块里面的app_cfg.h的内容如下：
#include "..\app_cfg.h"
#ifndef __XXX_APP_CFG_H__
#define __XXX_APP_CFG_H__
...
#endif
__XXX_APP_CFG_H__是保护宏，防止同样的内容被包含两次。
请务必注意到这一点：app_cfg.h一定会在保护宏之前包含上一级目录的app_cfg.h。
一个service是一个黑盒子，里面究竟怎么实现其实是无所谓的；但一定包含一个接口头文件和一个配制头文件。
需要强调一点，对于接口头文件来说，黑盒子里面的所有的.c和.h都不会去包含它——简单说就是接口头文件是一个孤立的头文件。
关于配制头文件，模块内所有的文件都会包含它。
这就是service封装的基本规则。
思考总结：
1、模块的.c和.h都包含app_cfg.h配置文件，是为了保持配置的一致性；
2、app_cfg.h要用下面这种形式包含上层模块的配置信息，是为了使程序
像搭积木一样，能够把最上层的配置信息准备传递给下面左右的模块；
#include "..\app_cfg.h"
#ifndef __XXX_APP_CFG_H__
#define __XXX_APP_CFG_H__
...
#endif
3、.c要用下面方式包含本模块的配置信息，是为了能够准备的包含的
本模块的配置信息，而没有歧义；
#include ".\app_cfg.h"
4、.h用下面的方式包含本模块的配置信息，是为了使配置信息仅仅被
调用模块包含，而不会被嵌套包含扩散；
#ifndef __XXX_APP_CFG_H__
#define __XXX_APP_CFG_H__
#include ".\app_cfg.h"
...
#endif