第六章 继承和面向对象设计(35-36)

第六章 继承和面向对象设计

很多人认为，继承是面向对象程序设计的全部。这个观点是否正确还有待争论，但本书其它章节的条款数量足以证明，在进行高效的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++来表示它们。
条款36: 区分接口继承和实现继承

（公有）继承的概念看起来很简单，进一步分析，会发现它由两个可分的部分组成：函数接口的继承和函数实现的继承。这两种继承类型的区别和本书简介中所讨论的函数声明和函数定义间的区别是完全一致的。

作为类的设计者，有时希望派生类只继承成员函数的接口（声明）；有时希望派生类同时继承函数的接口和实现，但允许派生类改写实现；有时则希望同时继承接口和实现，并且不允许派生类改写任何东西。

为了更好地体会这些选择间的区别，看下面这个类层次结构，它用来表示一个图形程序中的几何形状：

class Shape {
public:
  virtual void draw() const = 0;

  virtual void error(const string& msg);

  int objectID() const;

  ...

};

class Rectangle: public Shape { ... };

class Ellipse: public Shape { ... };

纯虚函数draw使得Shape成为一个抽象类。所以，用户不能创建Shape类的实例，只能创建它的派生类的实例。但是，从Shape（公有）继承而来的所有类都受到Shape的巨大影响，因为：

· 成员函数的接口总会被继承。正如条款35所说明的，公有继承的含义是 "是一个" ，所以对基类成立的所有事实也必须对派生类成立。因此，如果一个函数适用于某个类，也必将适用于它的子类。

Shape类中声明了三个函数。第一个函数，draw，在某一画面上绘制当前对象。第二个函数，error，被其它成员函数调用，用于报告出错信息。第三个函数，objectID，返回当前对象的一个唯一整数标识符（条款17给出了一个怎样使用这种函数的例子）。每个函数以不同的方式声明：draw是一个纯虚函数；error是一个简单的（非纯?）虚函数；objectID是一个非虚函数。这些不同的声明各有什么含义呢？

首先看纯虚函数draw。纯虚函数最显著的特征是：它们必须在继承了它们的任何具体类中重新声明，而且它们在抽象类中往往没有定义。把这两个特征放在一起，就会认识到：

· 定义纯虚函数的目的在于，使派生类仅仅只是继承函数的接口。

这对Shape::draw函数来说非常有意义，因为，让所有Shape对象都可以被绘制是很合理，但Shape类无法为Shape::draw提供一个合理的缺省实现。例如，绘制椭园的算法就和绘制矩形的算法大不一样。打个比方来说，上面Shape::draw的声明就象是在告诉子类的设计者，"你必须提供一个draw函数，但我不知道你会怎样实现它。"

顺便说一句，为一个纯虚函数提供定义也是可能的。也就是说，你可以为Shape::draw提供实现，C++编译器也不会阻拦，但调用它的唯一方式是通过类名完整地指明是哪个调用：

Shape *ps = new Shape;           // 错误! Shape是抽象的

Shape *ps1 = new Rectangle;      // 正确
ps1->draw();                     // 调用Rectangle::draw

Shape *ps2 = new Ellipse;        // 正确
ps2->draw();                     // 调用Ellipse::draw

ps1->Shape::draw();              // 调用Shape::draw

ps2->Shape::draw();              // 调用Shape::draw

一般来说，除了能让你在鸡尾酒会上给你的程序员同行留下深刻印象外，了解这种用法一般没大的作用。然而，正如后面将看到的，它可以被应用为一种机制，为简单的（非纯）虚函数提供 "比一般做法更安全" 的缺省实现。

有时，声明一个除纯虚函数外什么也不包含的类很有用。这样的类叫协议类（Protocol class），它为派生类仅提供函数接口，完全没有实现。协议类在条款34中介绍过，并将在条款43再次提及。

简单虚函数的情况和纯虚函数有点不一样。照例，派生类继承了函数的接口，但简单虚函数一般还提供了实现，派生类可以选择改写它们或不改写它们。思考片刻就可以认识到：

· 声明简单虚函数的目的在于，使派生类继承函数的接口和缺省实现。

具体到Shape::error，这个接口是在说，每个类必须提供一个出错时可以被调用的函数，但每个类可以按它们认为合适的任何方式处理错误。如果某个类不想做什么特别的事，可以借助于Shape类中提供的缺省出错处理函数。也就是说，Shape::error的声明是在告诉子类的设计者，"你必须支持error函数，但如果你不想写自己的版本，可以借助Shape类中的缺省版本。"

实际上，为简单虚函数同时提供函数声明和缺省实现是很危险的。想知道为什么，看看XYZ航空公司的这个飞机类的层次结构。XYZ公司只有两种飞机，A型和B型，而且两种机型的飞行方式完全一样。所以，XYZ设计了这样的层次结构：

class Airport { ... };      // 表示飞机

class Airplane {
public:
  virtual void fly(const Airport& destination);

  ...

};

void Airplane::fly(const Airport& destination)
{
  飞机飞往某一目的地的缺省代码
}

class ModelA: public Airplane { ... };

class ModelB: public Airplane { ... };

为了表明所有飞机都必须支持fly函数，而且因为不同型号的飞机原则上都需要对fly有不同的实现， 所以Airplane::fly被声明为virtual。但是，为了避免在ModelA类和ModelB类中写重复的代码，缺省的飞行行为是由Airplane::fly函数提供的，ModelA和ModelB继承了这一函数。

这是典型的面向对象设计。两个类享有共同的特征（实现fly的方式），所以这一共同特征被转移到基类，并让这两个类来继承这一特征。这种设计使得共性很清楚，避免了代码重复，将来容易增强功能，并易于长期维护 ---- 所有这一切正是面向对象技术高度吹捧的。XYZ公司真得为此而骄傲。

现在假设XYZ公司发了大财，决定引进一种新型飞机，C型。C型和A型、B型有区别，特别是，飞行方式不一样。

XYZ的程序员在上面的层次结构中为C型增加了一个类，但因为急于使新型飞机投入使用，他们忘了重新定义fly函数：

class ModelC: public Airplane {

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

然后，在程序中，他们做了类似下面的事：

Airport JFK(...);              // JFK是纽约市的一个机场

Airplane *pa = new ModelC;

...

pa->fly(JFK);                  // 调用Airplane::fly!

这将造成悲剧：竟然试图让ModelC对象如同ModelA或ModelB那样飞行。这种行为可不能换来旅客对你的信任！

这里的问题不在于Airplane::fly具有缺省行为，而在于ModelC可以不用明确地声明就可以继承这一行为。幸运的是，可以很容易做到为子类提供缺省行为、同时只是在子类想要的时候才给它们。窍门在于切断虚函数的接口和它的缺省实现之间的联系。下面是一种方法：

class Airplane {
public:
  virtual void fly(const Airport& destination) = 0;

  ...

protected:
  void defaultFly(const Airport& destination);
};

void Airplane::defaultFly(const Airport& destination)
{
  飞机飞往某一目的地的缺省代码
}

注意Airplane::fly已经变成了纯虚函数，它提供了飞行的接口。缺省实现还是存在于Airplane类中，但现在它是以一个独立函数（defaultFly）的形式存在的。ModelA和ModelB这些类想执行缺省行为的话，只用简单地在它们的fly函数体中对defaultFly进行一个内联调用（关于内联和虚函数间的相互关系，参见条款33）：

class ModelA: public Airplane {
public:
  virtual void fly(const Airport& destination)
  { defaultFly(destination); }

  ...

};

class ModelB: public Airplane {
public:
  virtual void fly(const Airport& destination)
  { defaultFly(destination); }

  ...

};

对于ModelC类来说，它不可能无意间继承不正确的fly实现。因为Airplane中的纯虚函数强迫ModelC提供它自己版本的fly。

class ModelC: public Airplane {
public:
  virtual void fly(const Airport& destination);
  ...

};

void ModelC::fly(const Airport& destination)
{
  ModelC飞往某一目的地的代码
}

这个方法不会万无一失（程序员还会因为 "拷贝粘贴" 而出错），但它比最初的设计可靠多了。至于Airplane::defaultFly被声明为protected，是因为它确实只是Airplane及其派生类的实现细节。使用airplane的用户只关心飞机能飞，而不会关心是怎么实现的。

Airplane::defaultFly是一个非虚函数也很重要。因为没有子类会重新定义这个函数，条款37说明了这一事实。如果defaultFly为虚函数，就会又回到这个问题：如果某些子类应该重新定义defaultFly而又忘记去做，那该怎么办？

一些人反对将接口和缺省实现作为单独函数分开，例如上面的fly和defaultFly。他们认为，起码这会污染类的名字空间，因为有这么多相近的函数名称在扩散。然而他们还是赞同接口和缺省实现应该分离。怎么解决这种表面上存在的矛盾呢？可以借助于这一事实：纯虚函数必须在子类中重新声明，但它还是可以在基类中有自己的实现。下面的Airplane正是利用这一点重新定义了一个纯虚函数：

class Airplane {
public:
  virtual void fly(const Airport& destination) = 0;

  ...

};

void Airplane::fly(const Airport& destination)
{
  飞机飞往某一目的地的缺省代码
}

class ModelA: public Airplane {
public:
  virtual void fly(const Airport& destination)
  { Airplane::fly(destination); }

  ...

};

class ModelB: public Airplane {
public:
  virtual void fly(const Airport& destination)
  { Airplane::fly(destination); }

  ...

};

class ModelC: public Airplane {
public:
  virtual void fly(const Airport& destination);

  ...

};

void ModelC::fly(const Airport& destination)
{
  ModelC飞往某一目的地的代码
}

这一设计和前面的几乎一样，只是纯虚函数Airplane::fly的函数体取代了独立函数Airplane::defaultFly。从本质上说，fly已经被分成两个基本部分了。它的声明说明了它的接口（派生类必须使用），而它的定义说明了它的缺省行为（派生类可能会使用，但要明确地请求）。然而，将fly和defaultFly合并后，就不再能够为这两个函数声明不同的保护级别了：本来是protected的代码（在defaultFly中）现在成了public（因为它在fly中）。

最后，来谈谈Shape的非虚函数，objectID。当一个成员函数为非虚函数时，它在派生类中的行为就不应该不同。实际上，非虚成员函数表明了一种特殊性上的不变性，因为它表示的是不会改变的行为 ---- 不管一个派生类有多特殊。所以，

· 声明非虚函数的目的在于，使派生类继承函数的接口和强制性实现。

可以认为，Shape::objectID的声明就是在说，"每个Shape对象有一个函数用来产生对象的标识符，并且对象标识符的产生方式总是一样的。这种方式由Shape::objectID的定义决定，派生类不能改变它。" 因为非虚函数表示一种特殊性上的不变性，所以它决不能在子类中重新定义，关于这一点条款37进行了讨论。

理解了纯虚函数、简单虚函数和非虚函数在声明上的区别，就可以精确地指定你想让派生类继承什么：仅仅是接口，还是接口和一个缺省实现？或者，接口和一个强制实现？因为这些不同类型的声明指的是根本不同的事，所以在声明成员函数时一定要从中慎重选择。只有这样做，才可以避免没经验的程序员常犯的两个错误。

第一个错误是把所有的函数都声明为非虚函数。这就使得派生类没有特殊化的余地；非虚析构函数尤其会出问题（参见条款14）。当然，设计出来的类不准备作为基类使用也是完全合理的（条款M34就给出了一个你会这样做的例子）。这种情况下，专门声明一组非虚成员函数是适当的。但是，把所有的函数都声明为非虚函数，大多数情况下是因为对虚函数和非虚函数之间区别的无知，或者是过分担心虚函数对程序性能的影响（参见条款M24）。而事实上是：几乎任何一个作为基类使用的类都有虚函数（再次参见条款14）。

如果担心虚函数的开销，请允许我介绍80-20定律（参见条款M16）。它指出，在一个典型的程序中，80%的运行时间都花在执行20%的代码上。这条定律很重要，因为它意味着，平均起来，80%的函数调用可以是虚函数，并且它们不会对程序的整体性能带来哪怕一丁点可以觉察到的影响。所以，在担心是否承担得起虚函数的开销之前，不妨将注意力集中在那20%会真正带来影响的代码上。

另一个常见的问题是将所有的函数都声明为虚函数。有时这没错 ---- 比如，协议类（Protocol class）就是证据（参见条款34）。但是，这样做往往表现了类的设计者缺乏表明坚定立场的勇气。一些函数不能在派生类中重定义，只要是这种情况，就要旗帜鲜明地将它声明为非虚函数。不能让你的函数好象可以为任何人做任何事 ---- 只要他们花点时间重新定义所有的函数。记住，如果有一个基类B，一个派生类D，和一个成员函数mf，那么下面每个对mf的调用都必须工作正常：

D *pd = new D;
B *pb = pd;

pb->mf();                    // 通过基类指针调用mf

pd->mf();                    // 通过派生类指针调用mf

有时，必须将mf声明为非虚函数才能保证一切都以你所期望的方式工作（参见条款37）。如果需要特殊性上的不变性，就大胆地说出来吧！