一、代码保护（减少库头文件对用户暴露的逻辑信息）：

发布动态库时，随库发布的头文件中可删除不对外公开的部分，减少暴露过多的逻辑信息给用户，以免扰乱他们的视听，这样用户就可以只关心自己要使用的部分就可以了，上图中我做了demo测试发现可以删除的信息有：

1.导出函数可选删除；

2.导出类公有接口可选删除；

3.导出变量可选删除；

4.非导出类需要删除；

5.导出类所有非公有部分需要删除；

6.非防止头文件包含的预编译语句可删除；

这也从实例反映出，在使用库时，头文件仅仅起到符号标识的作用，与头文件声明无关的非导出部分均可删除。

二、链接依赖（增强模块可复用度，使模块间关系清晰）：

1.C++的链接依赖是平面式的，循环依赖会使关系变得复杂，导致重用度大大降低；

2.链接依赖的高低取决于设计层面的合理性，但是循环依赖要尽可能避免；

3.如果库与库之间的相似度较高，可以提取出公共部分来降低连接依赖，应在设计时减少库与库的循环依赖为基本准则；

三、编译依赖（提高变更编译速度）：

1.代码依赖的减低取决于技术规范的合理运用；

2.列举一些技术点：

1.减少定义性依赖，如使用前置声明，同时也能避免循环依赖；

   2.尽量保证头文件中不必要的包含，尽量保证单编译依赖最小，尽量消除单编译时的警告信息，对于使用范围较大的稳定的

头文件（如标准库）可加入预编译；

   3.一般情况下，在C++中编译单元是由类组成，合理的抽象类，如不要定义动名词的类、保证继承is-a关系、合理组织has-a、use类间关系等等等技术有段，非常有可能有利于降低上层的编译依赖。具体可参考《OOD启思录》、《大规模C++程序设计》里面关于编译依赖的条款，酌情使用；

3.对于需要经常维护的编译单元，且其处于较高的层次时，可考虑酌情使用<<effective c++ 条款31 将文件间的依存关系降至最低>>，纯粹的减低依赖方式，甚至有点不惜一切代价；

 

4.加强code review，新增单元时，将单元间编译依赖纳入审查范围内；

5.新增主层次模块时，将链接依赖纳入评审流程；

6.增强人员平均OOD功底，加强对系统物理层次的理解及持续改进；