Effective C++ 2e Item35

继承和面向对象设计

很多人认为，继承是面向对象程序设计的全部。这个观点是否正确还有待争论，但本书其它章节的条款数量足以证明，在进行高效的C++程序设计时，还有更多的工具听你调遣，而不仅仅是简单地让一个类从另一个类继承。

然而，设计和实现类的层次结构与C语言中的一切都有着根本的不同。只有在继承和面向对象设计领域，你才最有可能从根本上重新思考软件系统构造的方法。另外，C++提供了多种很令人困惑的面向对象构造部件，包括公有、保护和私有基类；虚拟和非虚拟基类；虚拟和非虚拟成员函数。这些部件不仅互相之间有联系，还和C++的其它部分相互作用。所以，对于每种部件的含义、什么时候该用它们、怎样最好地和C++中非面向对象部分相结合 ---- 要想真正理解这些，就要付出艰苦的努力。

使得事情更趋复杂的另一个原因是，C++中很多不同的部件或多或少地好象都在做相同的事。例如：

? 假如需要设计一组具有共同特征的类，是该使用继承使得所有的类都派生于一个共同的基类呢，还是使用模板使得它们都从一个共同的代码框架中产生？

? 类A的实现要用到类B，是让A拥有一个类型为B的数据成员呢，还是让A私有继承于B？

? 假设想设计一个标准库中没有提供的、类型安全的同族容器类（条款49列出了标准库实际提供的容器类），是使用模板呢，还是最好为某个 "自身用普通（void*）指针来实现" 的类建立类型安全的接口呢？

在本章节的条款中，我将指导大家怎样去回答这类问题。当然，我不可能顾及到面向对象设计的方方面面。相反，我将集中解释的是：C++中不同的部件其真正含义是什么，当使用某个部件时你真正做了什么。例如，公有继承意味着 "是一个" （详见条款35），如果使它成为别的什么意思，就会带来麻烦。相似地，虚函数的含义是 "接口必须被继承"，非虚函数的含义是 "接口和实现都要被继承"。不能区分它们之间的含义会给C++程序员带来无尽的痛苦。

如果能理解C++各种部件的含义，你将发现自己对面向对象设计的认识大大转变。你将不再停留在为区分C++语言提供的不同部件而苦恼，而是在思考要为你的软件系统做些什么。一旦知道自己想做什么，将它转化为相应的C++部件将是一件很容易的事。

做你想做的，理解你所做的！这两点的重要性绝没有过分抬高。接下来的条款将对如何高效地实现这两点进行了详细的讨论。条款44总结了C++面向对象构造部件间的对应关系和它们的含义。它是本章节最好的总结，也可作为将来使用的简明参考。

条款35: 使公有继承体现 "是一个" 的含义

在"Some Must Watch While Some Must Sleep"（ W. H. Freeman and Company, 1974）一书中，William Dement讲了一个故事，故事说的是他如何让学生们记住他的课程中最重要的部分。"据说，"，他告诉他的学生，"一般的英国学生除了记得Hastings战役发生在1066年外，再也不记得其它历史。"， "如果一个小孩不记得别的历史，" Dement强调说，"也一定记得1066这个日子。"  但对于他班上的学生来说，只有很少一些话题可以引起他们的兴趣，比如，安眠药会引起失眠之类。所以他哀求他的学生，即使忘掉他在课堂上讲授的其它任何东西，也要记住那些仅有的几个重要的历史事件。而且，他在整个学期不停地对学生灌输这一基本观点。

学期结束时，期末考试的最后一道题是，"请写下你从课程中学到的一辈子都会记住的东西"。当Dement评改试卷时，他大吃一惊。几乎所有学生都写下了 "1066"。

所以，在这里我也以极度颤抖的声音告诉你，C++面向对象编程中一条重要的规则是：公有继承意味着 "是一个" 。一定要牢牢记住这条规则。

当写下类D（"Derived" ）从类B（"Base"）公有继承时，你实际上是在告诉编译器（以及读这段代码的人）：类型D的每一个对象也是类型B的一个对象，但反之不成立；你是在说：B表示一个比D更广泛的概念，D表示一个比B更特定概念；你是在声明：任何可以使用类型B的对象的地方，类型D的对象也可以使用，因为每个类型D的对象是一个类型B的对象。相反，如果需要一个类型D的对象，类型B的对象就不行：每个D "是一个" B， 但反之不成立。

C++采用了公有继承的上述解释。看这个例子：

class Person { ... };

class Student: public Person { ... };

从日常经验中我们知道，每个学生是人，但并非每个人是学生。这正是上面的层次结构所声明的。我们希望，任何对 "人" 成立的事实 ---- 如都有生日 ----也对 "学生" 成立；但我们不希望，任何对 "学生" 成立的事实 ---- 如都在某一学校上学 ----也对 "人" 成立。人的概念比学生的概念更广泛；学生是一种特定类型的人。

在C++世界中，任何一个其参数为Person类型的函数（或Person的指针或Person的引用）可以实际取一个Student对象（或Student的指针或Student的引用）：

void dance(const Person& p);        // 任何人可以跳舞

void study(const Student& s);       // 只有学生才学习

Person p;                           // p是一个人
Student s;                          // s是一个学生

dance(p);                           // 正确，p是一个人

dance(s);                           // 正确，s是一个学生，
                                    // 一个学生"是一个"人

study(s);                           // 正确

study(p);                           // 错误! p不是学生

只是公有继承才会这样。也就是说，只是Student公有继承于Person时，C++的行为才会象我所描述的那样。私有继承则是完全另外一回事（见条款42），至于保护继承，好象没有人知道它是什么含义。另外，Student "是一个" Person的事实并不说明Student的数组 "是一个" Person数组。关于这一话题的讨论参见条款M3。

公有继承和 "是一个" 的等价关系听起来简单，但在实际应用中，可能不会总是那么直观。有时直觉会误导你。例如，有这样一个事实：企鹅是鸟；还有这样一个事实：鸟会飞。如果想简单地在C++中表达这些事实，我们会这样做：

class Bird {
public:
  virtual void fly();               // 鸟会飞

  ...

};

class Penguin:public Bird {      // 企鹅是鸟

  ...

};

突然间我们陷入困惑，因为这种层次关系意味着企鹅会飞，而我们知道这不是事实。发生什么了？

造成这种情况，是因为使用的语言（汉语）不严密。说鸟会飞，并不是说所有的鸟会飞，通常，只有那些有飞行能力的鸟才会飞。如果更精确一点，我们都知道，实际上有很多种不会飞的鸟，所以我们会提供下面这样的层次结构，它更好地反映了现实：

class Bird {
  ...                   // 没有声明fly函数
};

class FlyingBird: public Bird {
public:
  virtual void fly();
  ...
};

class NonFlyingBird: public Bird {

  ...                  //  没有声明fly函数
};

class Penguin: public NonFlyingBird {

  ...                  //  没有声明fly函数
};

这种层次就比最初的设计更忠于我们所知道的现实。

但关于鸟类问题的讨论，现在还不能完全结束。因为在有的软件系统中，说企鹅是鸟是完全合适的。比如说，如果程序只和鸟的嘴、翅膀有关系而不涉及到飞，最初的设计就很合适。这看起来可能很令人恼火，但它反映了一个简单的事实：没有任何一种设计可以理想到适用于任何软件。好的设计是和软件系统现在和将来所要完成的功能密不可分的（参见条款M32）。如果程序不涉及到飞，并且将来也不会，那么让Penguin派生于Bird就会是非常合理的设计。实际上，它会比那个区分会飞和不会飞的设计还要好，因为你的设计中不会用到这种区分。在设计层次中增加多余的类是一种很糟糕的设计，就象在类之间制定了错误的继承关系一样。

对于 "所有鸟都会飞，企鹅是鸟，企鹅不会飞" 这一问题，还可以考虑用另外一种方法来处理。也就是对penguin重新定义fly函数，使之产生一个运行时错误：

void error(const string& msg);      // 在别处定义

class Penguin: public Bird {
public:
  virtual void fly() { error("Penguins can't fly!"); }

  ...

};

解释型语言如Smalltalk喜欢采用这种方法，但这里要认识到的重要一点是，上面的代码所说的可能和你所想的是完全不同的两回事。它不是说，"企鹅不会飞"，而是说，"企鹅会飞，但让它们飞是一种错误"。

怎么区分二者的不同？这可以从检测到错误发生的时间来区分。"企鹅不会飞" 的指令是由编译器发出的，"让企鹅飞是一种错误" 只能在运行时检测到。

为了表示 "企鹅不会飞" 这一事实，就不要在Penguin对象中定义fly函数：

class Bird {

  ...                          // 没有声明fly函数
                             
};

class NonFlyingBird: public Bird {

  ...                          // 没有声明fly函数
                              
};

class Penguin: public NonFlyingBird {

  ...                          // 没有声明fly函数
                              
};

如果想使企鹅飞，编译器就会谴责你的违规行为：

Penguin p;

p.fly();                       // 错误!

用Smalltalk的方法得到的行为和这完全不同。用那种方法，编译器连半句话都不会说。

C++的处理方法和Smalltalk的处理方法有着根本的不同，所以只要是在用C++编程，就要采用C++的方法做事。另外，在编译时检测错误比在运行时检测错误有某些技术上的优点，详见条款46。

也许你会说，你在鸟类方面的知识很贫乏。但你可以借助于你的初等几何知识，对不对？我是说，矩形和正方形总该不复杂吧？

那好，回答这个简单问题：类Square（正方形）可以从类Rectangle（矩形）公有继承吗？

        Rectangle
              ^
              ?
          Square

"当然可以！" 你会不屑地说，"每个人都知道一个正方形是一个矩形，但反过来通常不成立。" 确实如此，至少在高中时可以这样认为。但我不认为我们还是高中生。

看看下面的代码：

class Rectangle {
public:
  virtual void setHeight(int newHeight);
  virtual void setWidth(int newWidth);

  virtual int height() const;          // 返回当前值
  virtual int width() const;           // 返回当前值

  ...

};

void makeBigger(Rectangle& r)          // 增加r面积的函数
{                                     
  int oldHeight = r.height();

  r.setWidth(r.width() + 10);          // 对r的宽度增加10

  assert(r.height() == oldHeight);     // 断言r的高度未变
}                                    

很明显，断言永远不会失败。makeBigger只是改变了r的宽度，高度从没被修改过。

现在看下面的代码，它采用了公有继承，使得正方形可以被当作矩形来处理：

class Square: public Rectangle { ... };

Square s;

...

assert(s.width() == s.height());      // 这对所有正方形都成立

makeBigger(s);                        // 通过继承，s "是一个" 矩形
                                      // 所以可以增加它的面积
                                     
assert(s.width() == s.height());      // 这还是对所有正方形成立

很明显，和前面的断言一样，后面的这个断言也永远不会失败。因为根据定义，正方形的宽和高应该相等。

那么现在有一个问题。我们怎么协调下面的断言呢？

? 调用makeBigger前，s的宽和高相等；
? makeBigger内部，s的宽度被改变，高度未变；
? 从makeBigger返回后，s的高度又和宽度相等。（注意s是通过引用传给makeBigger的，所以makeBigger修改了s本身，而不是s的拷贝）

怎么样？

欢迎加入公有继承的精彩世界，在这里，你在其它研究领域养成的直觉 ---- 包括数学 ---- 可能不象你所期望的那样为你效劳。对于上面例子中的情况来说，最根本的问题在于：对矩形适用的规则（宽度的改变和高度没关系）不适用于正方形（宽度和高度必须相同）。但公有继承声称：对基类对象适用的任何东西 ---- 任何！---- 也适用于派生类对象。在矩形和正方形的例子（以及条款40中涉及到set的一个类似的例子）中，所声称的原则不适用，所以用公有继承来表示它们的关系只会是错误。当然，编译器不会阻拦你这样做，但正如我们所看到的，它不能保证程序可以工作正常。正如每个程序员都知道的，代码通过编译并不说明它能正常工作。

但也不要太担心你多年积累的软件开发直觉在步入到面向对象设计时会没有用武之地。那些知识还是很有价值，但既然你在自己的设计宝库中又增加了继承这一利器，你就要用新的眼光来扩展你的专业直觉，从而指导你开发出正确无误的面向对象程序。很快，你会觉得让Penguin从Bird继承或让Square从Rectangle 继承的想法很可笑，就象现在某个人向你展示一个长达数页的函数你会觉得可笑一样。也许它是解决问题的正确方法，只是不太合适。

当然，"是一个" 的关系不是存在于类之间的唯一关系。类之间常见的另两个关系是 "有一个" 和 "用...来实现"。这些关系在条款40和42进行讨论。这两个关系中的某一个被不正确地表示成 "是一个" 的情况并不少见，这将导致错误的设计。所以，一定要确保自己理解这些关系的区别，以及怎么最好地用C++来表示它们。