第34条： 区分清接口继承和实现继承
公有继承的概念看似简单，似乎很轻易就浮出水面，然而仔细审度之后，我们会发现公有继承的概念实际上包含两个相互独立的部分：函数接口的继承和函数实现的继承。二者之间的差别恰与函数声明和函数实现之间相异之处等价（本书引言中有介绍）。
假如你是一个类设计人员，某些场合下你需要使派生类仅仅继承基类成员函数的接口（声明）。而另一些时候你需要让派生类继承将函数的接口和实现都继承过来，但还期望可以覆盖继承来的具体实现。另外，你还可能会希望在派生类中继承函数的接口和实现，同时不允许覆盖任何内容。
为了获取上述三种选项的直观感受，可以参考下面的类层次结构实例，该实例用于在图形程序中表示几何形状：
class Shape {
public:
virtual void draw() const = 0;
virtual void error(const std::string& msg);
int objectID() const;
...
};
class Rectangle: public Shape { ... };
class Ellipse: public Shape { ... };
Shape 是一个抽象类，纯虚函数 draw 标示着这一点。因此客户端程序员便无法创建 Shape 类的实例，只能由 Shape 类继承出新的派生类。不过， Shape 对所有由它（公共）继承出的类有着深远的影响，因为
l 成员函数的接口总会被继承下来。就像第 12 条中所解释的，共公继承意味着“是一个”的关系，因此对于基类成立的任何东西，对于派生类也应成立。由此可知，如果一个函数应用于一个类中，那么它同样也存在于这个类的派生类中。
Shape 类 中声名了三个函数，第一个是 draw ，用于把当前对象绘制在一个假想的显示设备上。第二个是 error ，在成员函数需要报告错误时它将被调用。第三个是 objectID ，为当前对象返回一个标识身份的整数值。每个函数的声明方式各不相同： draw 是一个纯虚函数， error 是一个简单（非纯虚的）虚函数， objectID 是一个非虚函数。那么这些不同的声明方式的具体实现又是什么样的呢？
首先请看纯需函数 draw ：
class Shape {
public:
virtual void draw() const = 0;
...
};
纯虚函数最为显著的两个特征是：首先，在所有具体的派生类中，必须要对它们进行重新声明；其次，在一般情况下，纯虚函数在抽象类中没有定义内容。融合以上两点我们可以看出：
l 定义纯虚函数的目的就是让派生类仅仅继承函数接口。
对于 Shape::draw 函数来说上面的分析再恰当不过了，因 为“所 有的 Shape 对象必须能够绘制出 来”这 一要求十分合理，但是 “ 由 Shape 类来提供缺省的具体实现 ” 就显得很牵强了。比如说，绘制一个椭圆的算法与绘制一个长方形大相径庭。 Shape::draw 告诉具体派生类的设计 者：“你 必须要提供一个 draw 函数，但是我可不知道你要怎么 去实现它。”
顺便说一句，为纯虚函数提供一个定义并没有被 C++ 所禁止。也就是说，你可以为 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
上文所述的这一 C++ 特征，除了作为你在鸡尾酒会上的谈资以外，似乎真正的用处很有限。然而就像你在下文中见到的一样，这一特征也有一定的用武之地，它可以为简单（非纯）虚函数提供“超常安全”的默认具体实现。
简单虚函数的背后隐藏的内情与纯虚函数有些许不同。一般情况下，派生类继承函数接口，但是简单虚函数提供了一个具体实现，派生类中可以覆盖这一实现。如果你稍加思索，你就会发现：
l 声明简单虚函数的目的就是：让派生类继承函数接口的同时，继承一个默认的具体实现。
请观察以下情形中的 Shape::error ：
class Shape {
public:
virtual void error(const std::string& msg);
...
};
接口要求每个类必须要提供一个函数，以便在程序出错时调用，但是每个类都有适合自己的处理错误的方法。如果一个类并不想提供特殊的错误处理机制，那么它就可以返回调用 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 { ... };
此处 Airplane::fly 声 明为虚函数，这是为了表明所有飞机必须要提供 一个 fly 函数 ，同时也基于以下事实：理论上讲，不同型号的飞机需要提供不同版本的 fly 函数实现。然而，为了避免在 ModelA 和 ModelB 中出现同样的代码，我们将默认的飞行行为放置在 Airplane::fly 中，由 ModelA 和 ModelB 来继承。
这是一个经典的面向对象设计方案。当两个类共享同一特征（即它们实现 fly 的方式）时，我们将这一共同特征移动到一个基类中，然后由两个派生类来继承这一共同特征。这一设计方案使得共同特征显性化，避免了代码重复，为未来的更新工作提供了便利，减轻了长期维护的负担——所有的一切都是面向对象技术极力倡导的。 XYZ 航空公司应该感到十分骄傲了。
现在请设想： XYZ 公司有了新的业务拓展，他们决定引进一款新型飞机—— C 型。 C 型飞机在某些方面与 A 型和 B 型有着本质的区别，尤其是， C 型飞机的飞行方式与前两者完全不同。
XYZ 的程序员将 C 型飞机添加进层次结构，但是由于他们急于让新型飞机投入运营，他们忘记了重定义 fly 函数：
class ModelC: public Airplane {
... // 没有声明任何 fly 函数
};
于是，在他们的代码中将会遇到类似的问题：
Airport PDX(...); // PDX 是我家附近一个飞机场
Airplane *pa = new ModelC;
...
pa->fly(PDX); // 调用了 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 即可（请参见第 30 条中介绍的关于内联和虚函数之间的联系）：
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 中的纯虚函数 fly 强制 ModelC 提供自己版本的 fly 。
class ModelC: public Airplane {
public:
virtual void fly(const Airport& destination);
...
};
void ModelC::fly(const Airport& destination)
{
使 C 型飞机抵达目的地的代码
}
这一方案亦非天衣无缝（程序员仍然会“复制 / 粘贴”出新的麻烦），但是它至少要比原始的设计方案更可靠。至于 Airplane::defaultFly ，由于此处它是 Airplane 及其派生类真实的具体实现。客户端程序员只需要关注飞机可以飞行，而无须理会飞行功能是如何实现的。
Airplane::defaultFly 是一个非虚函数，这一点同样重要。这是因为任何派生类都不应该去重定义这一函数，这是第 36 条所致力于讲述的议题。如果 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)
{
使 C 型飞机抵达目的地的代码
}
这一设计方案与前一个几乎是一致的。只是这里用纯虚函数 Airplane::fly 代替了独立函数 Airplane::defaultFly 。从本质上讲，这里的 fly 被分割成了两个基本的组成部分，它的声明确定它的接口，而它的定义确定它的默认行为（派生类可以使用这一定义，但只有在现实请求的前提下才可以）。然而通过融合 fly 和 defaultFly ，你就失去了将这两个函数至于不同保护层次的能力：原先受保护的代码（ defaultFly 中的代码）现在是公共的了（因为这些代码移动到了 fly 中）。
最后，让我们把话题转向 Shape 中的非虚函数—— objectID ：
class Shape {
public:
int objectID() const;
...
};
当一个成员函数是非虚函数时，你不应该期待它会在不同的派生类中存在不同的行为。事实上，非虚拟的成员函数确立了一个超具体化的恒量，因为它确保了无论派生类多么千变万化，其行为不能被改变。也就是说：
l 声明一个非虚函数的目的就是让派生类继承这一函数的接口，同时强制继承其具体实现。
你可以把 shape::objectID 的声明想象成：每个 Shape 对象都有一个函数能生成“对象身份标识”的函数。这一“对象身份标识”总是以同一方式运行。这一方式由 Shape::objectID 的定义确定，任何派生类都不能偿试更改这一方式。因为虚函数确定了超具体化的恒量，所以在任何的派生类中都不允许重定义该函数，这一点将在第 36 条中详细讲解。
纯虚函数，简单虚函数和非虚函数，不同的声明方式使你能够精确地指定你的派生类需要继承什么：是仅仅继承接口，还是同时继承接口和实现，抑或接口和强制内容的实现。由于这些不同种类的声明意味着，在基础层面存在着不同，因此你在声明成员函数时，一定要仔细斟酌。如果你这样做了，那么你将避免缺乏经验的类设计人员常犯的两类错误：
首先，第一类错误是：将所有函数都声明为纯虚的。这样做可以说断送了派生类进行拓展的后路。非虚拟的析构函数更是陷阱重重（参见第 7 条）。当然，设计一个不需要作为基类的类无可厚非，这种情况下，清一色的一组非虚函数也是合乎情理的。然而，由于人们常常忽视虚函数和非虚函数之间的差异，还有非虚函数会对性能产生影响的无端猜疑。人们对于包含虚函数的类的接受程度并不高。但事实上，几乎每个需要充当基类的类都需要虚函数的支持。（同样请参见第 7 条）
如果你谈到虚函数的性能开销问题，请允许我引用现实中提炼出的“ 80-20 法则”（同样参见第 30 条），在一个典型的程序中， 80% 的运行时间将花费在 20% 的代码上。这一法则十分重要，因为它意味着在一般情况下， 80% 的虚函数调用将不会对你的程序的整体性能造成任何影响。与其为虚函数是否会带来无法承受的性能开销而顾忌重重，还不如把精力放在程序中真正会带来影响的那 20% 上。
另一个一般的问题是：将所有的成员函数都声明为虚函数。有时候这么做是正确的——第 31 条中的接口类就是证据。然而，这样做给人的印象就是这个类的设计者缺乏主心骨。在派生类中一些函数不应该进行重定义，你必须要通过将这些函数声明为非虚函数才能确保这一点。你应该清楚，并不是让客户端程序员去重定义所有的函数，你的类就成了万能的了。如果你的类中包含超具体化的衡量，那么就应该大胆的将其声明为非虚函数。
铭记在心
l 接口继承与实现继承存在着不同。在公共继承体系下，派生类总是继承基类的接口。
l 纯虚函数要求派生类仅继承接口。
l 简单（非纯）虚函数要求派生类在继承接口的同时继承默认的实现。
l 非虚函数要求派生类继承接口和强制内容的实现。