hao对《大规模C++程序设计》的笔记(10)
hao
读过 大规模C++程序设计
- 书名: 大规模C++程序设计
- 作者: John Lakos
- 页数: 624
- 出版社: 中国电力出版社
- 出版年: 2003.9
-
第25页 引言
不必要的编译时依赖
一个大型的C++程序通常会比同样的C程序有更多的头文件。一个文件包含不必要的头文件，是造成C++中过多耦合的原因。不管这些不必要的头文件是否会用到，过多的包含伪指令（#include），不仅会增加编译时的开销，而且也可能增加由于较低层次上改变了系统而必须重新编译整个程序的可能性。 如果忽略编译时依赖，那么有可能使得系统中每一个编译单元几乎包含每一个头文件，最终使整个工程项目编译变得跟爬行一样慢，这样会随着项目规模暴增。 引自 引言 不必要的全局空间污染
尽量别把typdef这样的类型定义放到类外，尽量放到类内，否则维护者不好找其定义。这样一来，声明新类型就可以：className::NewType object了。 遵循以上规则，就可以使冲突降到最低，同时使得在大系统中寻找逻辑实体更加容易。 引自 引言 物理设计
好的物理设计不仅仅是被动地决定系统的现有逻辑实体应如何划分。物理设计常蕴含要支配逻辑设计的输出。一个好的物理设计是一个没有循环的图。小项目物理设计不太重要，但是大型项目，物理设计往往是成功的关键。 引自 引言 -
第90页 基本规则
预处理宏
在.c或.cpp文件中预处理宏的好处才超过它们带来的问题。 除非是作为包含卫哨，否则在头文件中应避免使用预处理宏。 .h文件中最好不要有文件作用域范围的enum typedef extern const之类的变量定义，也不要有函数定义，即使是内联函数也不要轻易在头文件中定义。 引自 基本规则 -
第105页 组件
逻辑设计只研究体系结构问题；物理设计研究组织问题。 物理设计集中研究系统中物理实体以及它们如何相互关联的问题。大多数传统的C++程序中，系统中每一个逻辑实体的源代码都必须驻留在一个物理实体中，一般称之为一个文件。基本上每一个C++程序都可以描述为一个文件的集合，这些文件有一些是头文件，而有一些是实现文件。对于小型系统足够了，对于大型系统就需要利用额外的结构来生成可维护，可测试和可重用的子系统。 一个组件就是物理设计的最小单位。 组件不是类。在结构上，组件是一个不可分割的物理单元，没有哪一部分可以独立地用在其它的组件中，一个组件的物理形态是标准的，并且独立于它的内容。一个组件严格地由一个头文件（.h）和一个实现文件（.cpp）构成。（配对）。 一个组件一般会定义一个或多个紧密相关的类和被认定适合于所支持的抽象的任何自由运算符。 引自 组件 根据vczh的经验，他一般喜欢以文件来划分功能，那么我想可以等价于以组件来划分功能，一个功能划分为一个组件可能比较合适。
一个组件的物理接口就是它头文件中的所有东西。 引自 组件 物理设计规则
在一个组件内部声明的逻辑实体不应该在组件之外定义。对于一个可重用的组件来说，它必须合理地自我包含。 组成一个组件的.cpp和.h文件的名称应该严格匹配。比如stack.h stack.cpp 每个组件的.cpp文件都应该将包含它自己的.h文件的语句作为其代码的第一行有效的语句。 引自 组件 客户程序引用第三方库（组件）的时候应该包含直接提供类型定义的头文件，除非私有继承，应避免依赖一个头文件去包含另一个头文件。 引自 组件 对于上面，我的理解是，比如我们依赖库A（A.h,A.cpp），我们有个组件B也依赖库A，所以B.h中包含了A.h,但同时，我们的另一个组件C，它也依赖库A，它应该直接包含A.h，不应该为了图简单方便，直接包含B.h(B包含A)。可以看成，我们需要什么组件就直接用它的头文件，不要间接引用。
-
第128页 组件
依赖关系
如果组件y.c编译时需要x.h，那么就说明组件y对组件x的编译时依赖。 如果对象文件y.o(编译y.c产生的)，包含未定义的符号，在链接时，需要x.o来辅助解析这些外部符号，那么就说明组件y对组件x的链接时依赖。 一个编译时依赖，几乎总是隐含一个链接时依赖。 组件的依赖关系具有传递性。 引自 组件 分析依赖包含图
假如系统编译成功的话，基本上能由#include的包含关系，就可以推断出系统的物理依赖。 组件包含指导方针-------只有当组件x确实并实质性的使用了定义在y中的函数或类，才应该#include y.h。不然就必须删掉。如果不删除，会造成编译时耦合，拖慢编译速度。 引自 组件 -
第167页 物理层次结构
测试
对于整个设计的层次结构（类的层次结构）进行分布式测试，比只在最高层接口进行测试有效得多。A调用B，B调用C，那么A,B,C都要测试。不要仅仅测试A。 引自 物理层次结构 在一个设计良好的模块化子系统中，可以对许多组件进行隔离测试，也就是模块独立性越高越好，可以降低与系统集成的风险。 层次图
每一个有向非循环图都可以被赋予惟一的层次号，一个有循环的图则不能，所以，一个好的层次设计，最好的树状的。 在大多数真实情况下，大型软件的层次结构如果要被有效测试，那么它们必须是可层次化的。 分层测试就是为每个组件添加一个测试驱动程序。 引自 物理层次结构 
上图就是可划分层次的层次设计，没有循环依赖。可以有效测试。
-
第258页 层次化
同层次的循环依赖，可能导致升级为一个更高层的潜在问题。 在庞大的低层次的子系统中，循环物理依赖将最大程度的增加维护系统开销，也就是越低层的模块组件，应该越独立可靠才对。 如果同层的组件产生循环依赖，应该考虑把公有的依赖功能抽象为一个单独的，较低层次独立组件来共享。--------------代码降级。 引自 层次化 把一个系统分解为更小的组件，既可以使他更灵活，也可以使它更复杂，因为要与更多的部件（组件）一起协同工作了。 对回调的需求可能是系统不良整体设计的症状 引自 层次化 根据以上，异步的东西更难理解是正常的，有什么办法避免？
-
第367页 绝缘
绝缘，我不知道翻译是不是准确，我的理解就是C++中，声明与实现完全分离。
对于一个组件的实现不进行绝缘的决策，可能是基于该组件不是很广泛使用的认识。 绝缘轻量级的，被广泛使用的并且通过值返回的对象，会显著降低系统的运行时性能。对于大型系统来说，大型的，被广泛使用的对象，要尽早进行绝缘。 引自 绝缘 -
第423页 包
包，不知道是不是翻译问题，其实书中说的就是一个Library，一个.lib,.a,或者.dll，.so。或者是更加广义抽象的一个大型库（框架）。 所以书中才会说，给包增加命名空间，和类名字函数前缀。避免包之间的循环依赖，使包层次化。 包绝缘
包呈现了一种比组件更高层次的抽象，在设计包时，应该把它的输出头文件数量最小化，可以提高可用性。 引自 包 main程序
一个大型系统，应该是由很多main函数组成的，并不只是唯一一个main函数。系统并没有单一的顶部。比如Vsiual Studio IDE，有很多bin文件（编译器前端，后端，程序错误报告器等），各分其职。 引自 包 -
第503页 设计一个函数
尽量避免返回const的值。 比如const int func(); 函数的自定义类型参数尽量用引用，避免用指针和直接传值（直接传值造成对象拷贝，造成性能开销）。避免用指针是因为指针可以没有初值，而引用必须有值。 永远不要企图删除一个通过引用传递的对象。 如果无论何时，一个形参通过引用或指针传递其实参给一个函数，改函数既不修改也不存储它的可写地址，那么这个形参就应该声明为const。 避免将通过值传递给一个函数的形参声明为const。 void f(const int x){ //bad idea x++; //compile-time error } 引自 设计一个函数 在接口中使用基本类型
1.避免在接口中使用short，改为使用int 2.避免在接口中使用unsigned整数，应该改为int整数。 3.避免在接口中使用long，应该使用int或自定义的大整数类型 4.考虑在接口中对于浮点类型只使用double，除非有强制性的原因才使用float或long double 引自 设计一个函数 -
第563页 实现一个对象
在实现中使用基本类型
1.在已知安全的情况下，才可以允许使用short。 2.在实现中，也尽量不考虑用unsigned 引自 实现一个对象 在设计一个包，函数，组件时使用最简单有效的技术。
hao的其他笔记 · · · · · · ( 全部427条 )
- P2P网络技术原理与C++开发案例
- 5
- 大话移动通信
- 1
- 图解网络硬件
- 1
- 写给大家看的C++书
- 1
- Orange'S
- 1
- 虚拟机
- 1
- Linux Shell脚本攻略
- 3
- HTTP权威指南
- 3
- C++ API设计
- 8
- C++语言的设计和演化
- 5
- 构建嵌入式LINUX系统
- 3
- 七周七语言
- 15
- 链接器和加载器
- 1
- Windows网络与通信程序设计
- 2
- Windows核心编程(第5版)
- 16
- C++GUI Qt4编程
- 3
- 图解TCP/IP (第5版)
- 12
- Python学习手册
- 5
- 编写可读代码的艺术
- 14
- 你一定爱读的极简欧洲史
- 2
- 短码之美
- 1
- 程序员的自我修养
- 17
- 美国纽约摄影学院摄影教材（上）
- 2
- Win32多线程程序设计
- 8
- 竹林蹊径
- 4
- 鸟哥的Linux私房菜
- 4
- Linux/Unix设计思想
- 6
- 程序设计语言的形式语义
- 1
- Windows驱动开发技术详解
- 9
- 你必须知道的495个C语言问题
- 5
- Windows内核原理与实现
- 44
- PCI Express 体系结构导读
- 3
- 程序员的数学
- 5
- 深入浅出 MFC 第二版
- 2
- 并发的艺术
- 4
- 群和它的图象表示
- 1
- C语言接口与实现
- 1
- 致命元素
- 2
- 深入解析Windows操作系统
- 51
- Linux C编程一站式学习
- 13
- 淘宝技术这十年
- 1
- 高效程序的奥秘
- 1
- 花田半亩
- 1
- 于丹：重温最美古诗词
- 1
- 诛仙8（大结局）
- 1
- 深入理解计算机系统（原书第2版）
- 9
- C和指针
- 9
- 寒江独钓
- 5
- Windows程序设计
- 9
- 数据结构与算法分析
- 11
- 80X86汇编语言程序设计教程
- 3
- 琢石成器
- 30
- 数学分析教程
- 1
- 操作系统概念（第六版）
- 12
- 算法竞赛入门经典
- 10
- C++反汇编与逆向分析技术揭秘
- 12