发布动态库时,随库发布的头文件中可删除不对外公开的部分,减少暴露过多的逻辑信息给用户,以免扰乱他们的视听,这样用户就可以只关心自己要使用的部分就可以了,上图中我做了demo测试发现可以删除的信息有:
2.导出类公有接口可选删除;
3.导出变量可选删除;
4.非导出类需要删除;
5.导出类所有非公有部分需要删除;
这也从实例反映出,在使用库时,头文件仅仅起到符号标识的作用,与头文件声明无关的非导出部分均可删除。
二、链接依赖(增强模块可复用度,使模块间关系清晰):
1.C++的链接依赖是平面式的,循环依赖会使关系变得复杂,导致重用度大大降低;
2.链接依赖的高低取决于设计层面的合理性,但是循环依赖要尽可能避免;
3.如果库与库之间的相似度较高,可以提取出公共部分来降低连接依赖,应在设计时减少库与库的循环依赖为基本准则;
三、编译依赖(提高变更编译速度):
1.代码依赖的减低取决于技术规范的合理运用;
2.列举一些技术点:
1.减少定义性依赖,如使用前置声明,同时也能避免循环依赖;
2.尽量保证头文件中不必要的包含,尽量保证单编译依赖最小,尽量消除单编译时的警告信息,对于使用范围较大的稳定的
头文件(如标准库)可加入预编译;
3.一般情况下,在C++中编译单元是由类组成,合理的抽象类,如不要定义动名词的类、保证继承is-a关系、合理组织has-a、use类间关系等等等技术有段,非常有可能有利于降低上层的编译依赖。具体可参考《OOD启思录》、《大规模C++程序设计》里面关于编译依赖的条款,酌情使用;
3.对于需要经常维护的编译单元,且其处于较高的层次时,可考虑酌情使用<<effectivec++条款31将文件间的依存关系降至最低>>,纯粹的减低依赖方式,甚至有点不惜一切代价;
4.加强codereview,新增单元时,将单元间编译依赖纳入审查范围内;
5.新增主层次模块时,将链接依赖纳入评审流程;
6.增强人员平均OOD功底,加强对系统物理层次的理解及持续改进;
原文链接:https://www.f2er.com/javaschema/284529.html