Item 32: 确保 public inheritance 模拟 "is-a"
作者：Scott Meyers
译者：fatalerror99 (iTePub's Nirvana)
发布：http://blog.csdn.net/fatalerror99/
在 Some Must Watch While Some Must Sleep (W. H. Freeman and Company, 1974) 这本书中，William Dement 讲述了一个他试图让他的学生的记住他的课程中最重要的东西的故事。书中声称，他告诉他的班级，一般的英国中小学生对于 1066 年发生的 Hastings 战争的历史并没有什么了解。他着重强调，如果一个孩子记住了一点儿什么的，他或者她也就是记住了 1066 这个年代。对于上他的课程的学生，Dement 滔滔不绝地讲，其中只有很少的重要信息，包括安眠药却引起了失眠这样充满趣味的事情。他希望他的学生即使忘记课程中讨论的其它每一件事，也能记住这些很少的重大事件，而且他在整个学期再三地回顾这些基础的内容。
在课程结束的时候，期末考试的最后一道题是：“写下从这个课程中得到的，你一生都将确切地记住的一件事。”当 Dement 给这次考试打分的时候，他几乎晕了过去。几乎每一个人都写了"1066"。
因此，我一再煞费苦心地向你宣扬，使用 C++ 语言进行 object-oriented programming 时唯一最重要规则就是：public inheritance（公开继承）意味着 "is-a"。要让这个规则刻骨铭心。
如果你写了一个 class D ("Derived") 从 class B ("Base") 公开继承，你就是在告诉 C++ 编译器（以及你的代码的读者）每一个类型为 D 的对象也是一个类型为 B 的对象，但是反之则不然。你就是在说 B 描绘了一个比 D 更一般的概念，D 描述了一个比 B 更特殊的概念。你就是在声称一个类型为 B 的对象可以使用的任何地方，一个类型为 D 的对象一样可以使用，因为每一个类型为 D 的对象也就是一个类型为 B 的对象。另一方面，如果你需要一个类型为 D 的对象，一个类型为 B 的对象则不行：每一个 D 都是一个 B，但是反之则不然。
C++ 坚持对 public inheritance 的这一解释。考虑这个例子：
class Person {...};
class Student: public Person {...};
我们从日常的经验知道每一个学生都是一个人，但并不是每一个人都是一个学生。这就是由这个继承体系严格确定的意义。我们期望每一件对于人来说成立的事情——例如，他或她有一个出生日——对于一个学生来说也成立。我们不期望每一件对于学生来说成立的事情——例如，他或她在一所特定的学校注册——对于普通人来说也成立。一个人的概念比一个学生的概念更普通，一个学生一个专门类型的人。
在 C++ 领域中，任何期望引数类型为 Person（或 pointer-to-Person 或 reference-to-Person）的函数都可以接受一个 Student object（或 pointer-to-Student 或 reference-to-Student）：
void eat(const Person& p); // anyone can eat
void study(const Student& s); // only students study
Person p; // p is a Person
Student s; // s is a Student
eat(p); // fine, p is a Person
eat(s); // fine, s is a Student,
// and a Student is-a Person
study(s); // fine
study(p); // error! p isn't a Student
这一点只对 public inheritance 才成立。只有 Student 以 public 方式从 Person 派生，C++ 才有我所描述的行为。private inheritance 意味着完全不同的其它事情（参见 Item 39），而 protected inheritance 究竟意味什么使我困惑至今。
public inheritance 和 is-a 等价听起来简单，但有时你的直觉会误导你。例如，企鹅是一种鸟没有问题，而鸟能飞也没有问题。如果我们天真地试图用 C++ 来表达，我们就会得到：
class Bird {
public:
virtual void fly(); // birds can fly
...
};
class Penguin:public Bird { // penguins are birds
...
};
突然间我们遇到了麻烦，因为这个继承体系表示企鹅能飞，我们知道这不是真的。发生了什么呢？
在这种情况下，我们成了不严谨的语言——英语的牺牲品。当我们说鸟能飞的时候，我们的意思并非是说所有种类的鸟都能飞，我们不过是说，大体上，鸟有飞的能力。如果我们说得更准确些，我们应该承认有几种不能飞的鸟，并提出如下继承体系，它对事实的模拟要好得多：
class Bird {
... // no fly function is declared
};
class FlyingBird: public Bird {
public:
virtual void fly();
...
};
class Penguin: public Bird {
... // no fly function is declared
};
这个继承体系比最初的设计更忠实于我们真正知道的东西。
至此我们还是没有完全做好关于这些鸟的事情，因为对于某些软件系统来说，可能并不需要区分能飞的和不能飞的鸟。如果你的应用程序对于鸟喙和鸟翼做了很多处理，而不打算对飞行做什么处理的话，最初的 two-class 的继承体系可能完全适用。它是对“没有一个适用于所有软件的完美设计”这样的事实的一个简单反映。最好的设计依赖于系统究竟期望做什么，无论现在还是未来。如果你的程序对飞行一无所知，而且也不期望以后能知道些什么，那么不分辨能飞与不能飞的鸟可能就是一个非常完美的设计决策。事实上，它可能比区分它们的设计更为可取，因为你试图模拟的世界中就没有这样一种区分。。
对于如何处理我所说的“所有的鸟能飞，企鹅是鸟，企鹅不能飞，啊……哦……”的问题，还有另一种思想观念。那就是为企鹅重定义 fly 函数，以便让它产生一个运行时错误。
void error(const std::string& msg); // defined elsewhere
class Penguin: public Bird {
public:
virtual void fly() { error("Attempt to make a penguin fly!");}
...
};
认可“这里所说的一些事情与你所想的可能不同”是很重要的。这不是说“企鹅不能飞”。而是说“企鹅能飞，但对它试图真的这样做就是一个错误”。
你能说出其中的区别吗？从错误被发觉时间方面看。“企鹅不能飞”的禁令可以由编译器强令执行，但是对“让企鹅真的去飞是一个错误”的规约的违反，只有在运行时才能被发觉。
为了表达“企鹅不能飞”这个限制，你要确保不要为 Penguin 对象定义这样的函数：
class Bird {
... // no fly function is declared
};
class Penguin: public Bird {
... // no fly function is declared
};
如果你现在试图让企鹅飞，编译器将因为你的违例而惩罚你：
Penguin p;
p.fly(); // error!
这与你采用产生运行时错误的方法，得到完全不同的行为。使用那个方法，关于对 p.fly 的调用，编译器一言不发。Item 18 解释了好的接口可以在编译时防止非法代码，所以你应该用通过编译器阻止企鹅飞翔企图的设计代替只在运行时检测的设计
也许你会承认你的鸟类学知识可能不足，但是你对自己对基本几何学的掌握很自信，是吗？我的意思是说，矩形和正方形能有多么复杂？
好吧，回答这个简单的问题：应该让 class Square 从 class Rectangle 公开继承吗？
“咄！”你说，“当然应该！每一个人都知道一个正方形就是一个矩形，但是反过来就不一定了。”这完全正确，至少在学校里是。但是我不认为我们现在还在学校里。
考虑如下代码：
class Rectangle {
public:
virtual void setHeight(int newHeight);
virtual void setWidth(int newWidth);
virtual int height() const; // return current values
virtual int width() const;
...
};
void makeBigger(Rectangle& r) // function to increase r's area
{
int oldHeight = r.height();
r.setWidth(r.width() + 10); // add 10 to r's width
assert(r.height() == oldHeight); // assert that r's
} // height is unchanged
很清楚，断言应该永远不会失败。makeBigger 仅仅改变了 r 的宽度，它的高度始终没有变化。
现在，考虑以下代码，使用 public inheritance 使得 squares 可以像 rectangles 一样进行处理：
class Square: public Rectangle {...};
Square s;
...
assert(s.width() == s.height()); // this must be true for all squares
makeBigger(s); // by inheritance, s is-a Rectangle,
// so we can increase its area
assert(s.width() == s.height()); // this must still be true
// for all squares
和刚才那个一样明显，第二个断言也应该永远不会失败。根据定义，正方形的宽度和高度是相等的。
但是，现在有一个问题，我们怎样才能协调以下断言？
调用 makeBigger 之前，s 的高度和它的宽度相等；
在 makeBigger 内，s 的宽度发生变化，但是它的高度没有变化；
从 makeBigger 返回之后，s 的高度还要和它的宽度相等。（注意 s 是通过 by reference 方式传入 makeBigger 的，所以 makeBigger 能改变 s 自身，而不是 s 的拷贝。）
嘟嘟？
欢迎来到 public inheritance 的奇妙世界，你在其它学习领域——包括数学——中发展起来的本能，可能不再像你所期望的那样帮助你。在这种情况下，基本的难点在于一些适用于矩形（它的宽度可以独立于他的高度而自行变化）的事情不适用于正方形（它的宽度和高度必须相等）。但是 public inheritance 断言，适用于 base class objects（基类对象）的每一件事——每一件事！——也适用于 derived class objects（派生类对象）。在矩形和正方形的情况下（还有 Item 38 中一个包含 sets 和 lists 的例子），这个断言失效，所以用 public inheritance 模拟它们的关系是完全错误的。编译器允许你这样做，但是就像我们已经看到的，它不能保证代码的行为正确。每一个程序员都必须认识到，仅仅通过编译的代码，并不意味着它可以工作。
不必忧虑你在过去这些年发展起来的软件直觉在你走近 object-oriented design 时失效。那些知识依然是有价值的，但是现在你应该在你的设计候选武器库中加入 inheritance，你还必须在你的直觉中加入新的洞察力来指导你正确使用 inheritance。当某个人向你展示一个几页长的函数时，你可能会及时地从 Penguin 继承自 Bird 或 Square 继承自 Rectangle 得到有趣的感觉。它可能是接近事实的正确方法，只是不太像而已。
is-a 关系并不是能存在于两个 classes 之间的唯一关系。另外两个常见的 inter-class 关系是 "has-a" 和 "is-implemented-in-terms-of"。这些关系将在 Item 38 和 39 中考虑。因为用这些其它重要关系中的一个来不正确地模拟 is-a 而造成的 C++ 设计错误并不罕见，所以你应该确保你理解了这些关系之间的不同，并知道在 C++ 中如何才能用它们做最好的模拟。
Things to Remember
- public inheritance 意味着 "is-a"。适用于 base classes 的每一件事也适用于 derived classes，因为每一个 derived class object 都是一个 base class object。