《大规模C++程序设计》读书笔记22

Technorati 标签: C++,大规模C++程序设计,读书笔记

定义38：一个包（package）就是被组织成一个物理内聚单位的组件集合。

定义39：如果包x中的一个或多个组件依赖（DependsOn）另一个包y中的一个或多个组件，则称包x依赖（DependsOn）包y。

包反映了开发组织结构，跨越包边界的变化会影响其他开发者，甚至影响整个系统，因此应该将高度耦合的部分作为单个包的一部分。

主要设计规则12：为每个全局标识符都附加它的包前缀。

每个定义在文件作用域中的标识符都必须加上一个注册的前缀，以确保避免跨越包边界的名称冲突。

主要设计规则13：为每一个源文件名附加上它的包前缀。

原则72：前缀的主要用途是唯一的标识定义组件或类的物理包。

原则73：理想状态是，包前缀不仅表示定义组件或类的物理库，还将暗示包内聚的逻辑特征和组织特征。

主要设计规则14：避免包之间的循环依赖。

原则74：给被一个多包子系统的客户直接使用的组件子集指定一个单一包前缀并不是一定可能的。

原则75：在把一个新组件加入到包中时，这个组件的逻辑特性和物理特性都应该考虑。

原则76：最小化输出头文件的数量和大小，可以提高可用性。

定义40：包群（package group）就是一个包的集合，它被组织成一个物理上内聚的单位。

定义41：如果包群g中的一个或多个包依赖（DependsOn）另一个包群h中的一个或多个包，则称包群g依赖（DependsOn）包群h。

原则77：在一个包群内将协议降级和将包装器升级，有助于避免输出（展示）包和非输出（实现）包之间的循环依赖。

定义42：一个层（layer）对应于在系统的一个给定层次上的所有包群。

原则78：最小化修改之后的源代码的重编译时间，可以显著的减少开发开销。

定义43：补丁（patches）是对前一次发布软件的局部修改，以修补组件内的不完善或效率很低的功能。

原则79：补丁一定不能影响任何已存在对象的内部布局。

原则80：从一个定义了main的编译单元中分解出独立可测试的和潜在可重用的功能，本质上能够使程序的整个实现在一个更大型的程序中重用。

一个定义main的编译单元的用途是，提供一个有命令行接口、解释环境变量和管理全局资源的C++子系统。不要在定义main的文件中放置太多的代码，这些代码不能用C++测试驱动程序进行增量式测试，也不能在一个更大的C++程序中重用。

指导方针9：通常，避免赋予一个组件一种可被其他组件拥有的特权，否则将对作为一个整体的系统产生不利影响。

主要设计规则15：只有定义了main的.c文件才有权重新定义全局new和delete。

定义44：启动时间，也称为启用（invocation）时间，就是程序被初次调用和控制线程进入main之间的时间。

在这段时间里，每个编译单元的所有非局部静态对象被潜在的构造。

指导方针10：宁愿要模块而不要对象的非局部静态实例，尤其是在一下情况下：

1. 需要在一个编译单元之外对结构进行直接访问。
2. 该结构在启动期间不需要或在启动之后不是马上需要，并且初始化结构本身的时间是显著的。

原则81：程序中的每一个非局部静态对象结构都会潜在的增加启用时间。

原则82：初始化你不另外直接依赖的组件会显著的增加CCD。

主要设计规则16：提供一种机制来释放分配给一个组件内静态结构的任何动态内存。