大型项目开发: 隔离 (《大规模C++程序设计》书摘)

书中第六章 隔离。 主要在撰述什么须要定义在头文件？什么应当移到编译单元中？

核心仍然是先区分接口定义与实现细节。实现细节的改变会导致客户代码的又一次编译，从逻辑上也表示与客户代码间可能存在着强耦合。

实现细节与隔离

主要考察下面实现细节。它们会在接口中引入实现细节。也是须要考虑进行隔离的内容：

1. 继承
2. 分层
   
   简单的说就是类的成员中有还有一个类的实例时，如Foo mFoo. 这个类就会依赖于Foo的定义。而转为持有地址时，即将关系从HasA改为HoldA时，就不存在这个问题。也就是定义为Foo* mFoo;或Foo& mFoo; 这也是Google C++ Coding Style以前就降低头文件依赖建议过的方式，后来则去掉了这项建议，改为：”不要为了使用前置声明，将成员变量改为指针类型”, 由于它反而添加了逻辑上的复杂度，比方额外的判空处理。
3. 内联函数
4. 私有成员
5. 保护成员
6. 编译器生成的默认实现函数，如拷贝。
7. 包括指令，即头文件的包括。
8. 默认參数
9. 枚举
   
   在一些大型项目中。一些存有基本枚举类型的头文件。最后变成没人敢改，而更愿意新增头文件。事实上还不如放到详细的域或类中定义。

后面作者对各个细节推荐一些手法。相对照较简单。后面则介绍了几个经常使用手法:

1. 协议类(接口类)
2. Opaque Pointer和PIMPL
3. Wrapper (封装器), 即引入中间层。

过程接口

考虑到上层代码对底层的操作需求。作者提出了过程接口(The Procedural Interface),能够结合常见的API来理解，它是一组函数的集合。出如今组件的顶部，并将功能的一个子集暴露给用户。

作者概括了编程接口的要求:

1. 接口必须提供必要的功能来操纵底层系统。

2. 接口一定不能暴露专属的实现细节。
3. 底层组织的变化必须与client程序相隔离。
4. 与该接口相关的开销一定不能过大。

在实现方式上，以面向对象的Wrapper来实现这种需求最佳的。而过程接口将针对无法简单使用独立的封装类来实现的系统。

事实上一个大型系统也是能够拆分出不同的领域。分别以Wrapper的形式来实现的。能够对照WebView的接口。以及Blink中的web层次。

书中主要是探讨了针对所持有对象的操作。

上面也提到的Opaque Pointer。还特别说明了Handle(句柄)模式来管理动态分配的对象。

一个过程接口既不是面向对象的也不是特别美观。但它确有一个非常大的长处:过程接口总是能够用于将大系统的组织与client程序相隔离–即使在设计的早期阶段并没有考虑这种接口。

隔离或不隔离

隔离会引入一些开销。选择是否进行隔离的常见原因包括:

1. 暴露 (被使用的范围。或者扇入)
2. 訪问数据的性能
3. 创建对象的性能
4. 开发成本 （在没有明白理由的情况强行隔离。会引入额外的开发工作）
5. 组件的数量 (可能会新增组件，添加维护成本)
6. 组件的复杂性 （引入新的复杂度。导致难以理解和维护）

作者提供两套经验值供决策时參考（中文编译的图表不太严谨，第5章有图标错。这里明明是两个表，却合成了一个表。）。

訪问的相对开销

1. 内联函数传递值 : 1
2. 内联函数传递指针 : 2
3. 非内联函数，非虚函数 : 10
4. 虚函数机制 : 20

创建相对于单独分配的成本

1. 自己主动 (栈上) : 1.5
2. 动态 (堆上) : 100+

作者最后讨论隔离决策时，建议是否进行隔离取于被使用的范围，性能要求的高低，以及成员函数的大小（是否轻量级）。性能要求高不要隔离。轻量级的实现也不须要隔离。

事实上就是隔离本身会引入开销。假设为了隔离引入的开销过式，或者引入更不稳定的复杂度。就不要急于隔离。而对于大型、广泛使用的对象则要尽早隔离。