C++ 类层次结构的设计方法学
作者：Breaker <breaker.zy_AT_gmail>
关于 C++ 类层次结构的设计方法学，note-to-self + keynote + cross-reference 式笔记
本文精炼于 [CPP LANG] 12.4, 15.2 的 BBWindow 示例，只涉及 design
Syntax 参考 [CPP LANG] Ch12, 15; [CPP PRIMER] Ch17, 18
Play with bits 参考 [CPP OBJMODEL] 5.2
keyword: class hierarchy, multiple inheritance, abstract class, virtual base class, abstract factory, clone
目录
示例场景^
IValBox: 取得用户输入整数的 GUI 元素之抽象类，它不绑定具体 GUI 元素，如 slider 滑块, dial 拨盘
IValSlider: 滑块式 IValBox 实现，类似的还有 IValDial 拨盘式实现，代表 IValBox 类层次中具体的 GUI 元素。这些类可以进一步扩展，如从 IValSlider 派生出 PopupIValSlider
BBWindow: 第三方提供的 GUI 元素实现，类似 MFC 的 CWnd 等。IValBox 的类层次依靠 BBWindow 的类层次实现 GUI 特性（画图之类）。BBWindow 只是形式名，它可以替换，其意义就像将 MFC 换成 Qt 一样，这使得 IValBox 的类层次能够减小对特定 GUI 元素实现的依赖
UML: Old Hierarchy
设计要义：
-
使用 BBWindow 不是 IValBox 概念的基本部分。过分依赖 BBWindow，使得 BBWindow 难于替换
-
可变数据是实现的部分，当它侵入接口（抽象类）时，会影响接口的灵活性
-
Two-type interfaces: public interface vs. protected interface
interface: 有译接口，有译界面；有时代表函数，有时代表函数之聚集处（类、名字空间），凭上下文判断。按 [EFFECT CPP] Item 18 的说法：每一种接口都是客户与你的代码互动的手段
public interface: 给用户使用
protected interface: 给派生类使用Strict Guide: Data members are better kept private so that writers of derived classes cannot mess with them.
推论: A protected interface should contain only functions, types, and constants.
更多 private data member 的讨论见 [EFFECT CPP] Item 22Over strict?
Old Hierarchy 是不是 bad design？实际上我用 MFC 时，大多数时候都这样做，这是大多数人用 GUI 框架的方法
问题不在绝对的 bad design 或 good design，而在于目标是什么？Application Development vs. Library Development, Cross-platform vs. Dedicated-platform下面的改进设计比 Old Hierarchy 灵活而光鲜，但也带来的额外的负担（如理解和维护），Pros and Cons 自行抉择
分离实现和接口^
UML: Separate Implementation and Interface
接口线：接口继承形成的层次
实现线/扩展线：实现继承形成的层次
设计要义：
-
public 继承 vs. protected/private 继承
另一种表述是：接口继承 vs. 实现继承，见 [EFFECT CPP] Item 40。注意 Item 34 和这个设计无关，虽然标题相同，但那个是 for member function 的，这里是 for class 的
public 继承塑模 "is-a" 的关系（见 [EFFECT CPP] Item 32），而 protected/private 塑模 "implemented-in-terms-of" 的关系（见 [EFFECT CPP] Item 39）
protected 和 private 的区别：private 之实现止于直接派生类，而 protected 之实现可以进一步扩展
-
替代技术：public 继承 + Composition 复合
当用于实现域时，复合塑模 "implemented-in-terms-of" 的关系（和 protected/private 继承相同），见 [EFFECT CPP] Item 38
采用 protected/private 继承还是复合的判断，见 [EFFECT CPP] Item 39，如继承会造成 EBO (Empty Base Optimization) 空白基类最优化
替换实现^
这是分离实现和接口后得到的益处
UML: Substitute Implementation
图中的 BBSlider 表示 BBIValSlider 可藉由以存在的更特定的 GUI 元素实现，而不是更一般的 BBWindow，就像是从 MFC 的 CWnd 改为了 CSliderCtrl
使用同样的方法进行扩展就能得到 Big One:
UML: Substitute Implementation, Complicated
无需纠结上图具体含义，这里的设计推论更有意思：一个系统展现给用户的应该是一个抽象类的层次结构，其实现所用的是一个传统的层次结构
有点教条吧？试问，传统的层级结构从何而来？我们要做一个横跨多种 GUI 框架之上的框架么？
重复基类^
用 virtual 基类消除 replicated base class 重复基类，见 [EFFECT CPP] Item 40
这种用法的目的有二：
- 粘合 (glue) 两个不相干的类。这是我们应该忘掉的 virtual 多继承，连 Bjarne 也说它是 crude, effective, and important, but not very interesting.
- 为了下面的共享实现，这是有逻辑意义的
共享实现^
UML: Share Implementation
这里 Diamond-shaped Inheritance 钻石形继承的意义：让实现 PopupIValSlider 的类（即 BBPopupIValSlider）共享实现 IValSlider 的类（即 BBIValSlider）中的实现，以减少编码
于是另一个有意思的推论：组成应用之接口的抽象类的所有派生都应该是 virtual 的，[EFFECT CPP] Item 40 也说 public 继承应该总是 virtual
但是现实不能如此，最简短的反驳是效率因素，见 [CPP LANG] 15.2.5 和 [EFFECT CPP] Item 40
可藉由无 data member class 进行重复基类方式的优化
于是，饶了一圈又回来了
抽象工厂^
构造函数不可能是 virtual 的，道理很简单：不知道对象的确切类型，又如何构造它（构造函数的实质是对象内布局的 bits 初始化）
抽象工厂和 Clone 模式被戏称为 virtual constructor 虚拟构造函数，因为它们用 virtual 函数迂回完成构造函数的任务：根据某些线索创建对象
- 对于真的构造函数，线索是构造函数之参数
- 对于抽象工厂，线索是程序初始化时的预先设置。它的形态（典型的）可以是类的 UUID 标识 (e.g. COM's IClassFactory)
- 对于 Clone 模式，线索是当前对象之确切类型
绝对的抽象创建（没有线索）是不可能的，即没有语法支持（virtual 构造函数），也没有逻辑意义：当你想要铅笔时，可以说我要铅笔，也可以说我要铅笔盒中的东西（带线索的抽象），但不能只说我要东西（不带线索的抽象）
Why abstract class?
UML: Abstract Factory
减小对象创建时，对特定实现类（构造函数）的依赖，如当创建 IValDial 时，必须使用 BBIValDial 或 LSIValDial 的构造函数
当抽象类层次结构较复杂时，并且有从一个实现系统变为另一个实现系统（如从 BBWindow 变为 LSWindow）的预期时，需要一种一次性装入实现系统中各种创建对象的方法，这时抽象工厂就会发挥作用：
- 创建具体工厂类对象
- 将具体工厂类对象装入抽象工厂类对象（引用、指针）
- 用抽象工厂类对象创建抽象构造块类
- 使用抽象构造块类的方法，它动态绑定到具体构造块类的方法
1、2 是程序初始化阶段执行的设置，3、4 是程序例行阶段的行为
于是，抽象工厂是和抽象类层次伴生的
Clone 模式^
UML: Clone Pattern
Why clone?
手上有一个对象，只知道它的抽象类型（确切类型已丢失），要复制这种对象的大量副本，并且副本要和其确切类型一致
可以定义一个 Clonable 抽象基类，以规约 clone 函数，但不是必须的
Clone 模式可从函数 override 的返回值类型的 covariance 协变中受益。VC 2005+ 支持协变
参考书籍^
- [CPP LANG] "The C++ Programming Language, Special Ed", Bjarne Stroustrup
- [EFFECT CPP] "Effective C++, 3Ed", Scott Meyers
- [CPP PRIMER] "C++ Primer, 3Ed", Stanley Lippman, Josee Lajoie
- [CPP OBJMODEL] "Inside The C++ Object Model", Stanley Lippman