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

设计要义：

  1. 使用 BBWindow 不是 IValBox 概念的基本部分。过分依赖 BBWindow，使得 BBWindow 难于替换

  2. 可变数据是实现的部分，当它侵入接口（抽象类）时，会影响接口的灵活性

  3. 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

接口线：接口继承形成的层次
实现线/扩展线：实现继承形成的层次

设计要义：

  1. 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 之实现可以进一步扩展

  2. 替代技术：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

这种用法的目的有二：

  1. 粘合 (glue) 两个不相干的类。这是我们应该忘掉的 virtual 多继承，连 Bjarne 也说它是 crude, effective, and important, but not very interesting.
  2. 为了下面的共享实现，这是有逻辑意义的

共享实现^

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. 使用抽象构造块类的方法，它动态绑定到具体构造块类的方法

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

posted on 2012-05-27 19:30  Hibernate4  阅读(1843)  评论(0)  编辑  收藏  举报

导航