[面向对象] C++ 类层次结构的设计方法学

萧闫子 · 发表于 2014-1-10 09:57:37

作者：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 22
Over 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 函数迂回完成构造函数的任务：根据某些线索创建对象