⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 ei35.htm

📁 一个非常适合初学者入门的有关c++的文档
💻 HTM
📖 第 1 页 / 共 2 页
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd">
<HTML LANG="EN">
<HEAD>
<title>Effective C++, 2E | Item 35: Make sure public inheritance models "isa"</TITLE>
<LINK REL=STYLESHEET HREF=../INTRO/ECMEC.CSS>

<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/COOKIE.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/IMGDOC.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/NSIMGDOC.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">var imagemax = 2; setCurrentMax(2);</SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/DINGBATS.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">
var dingbase = "EI35_DIR.HTM";
var dingtext = "Item E35, P";
if (self == top) {
 top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>

</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- SectionName="E35: Make sure public inheritance models 'isa'" -->

<A NAME="6914"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EINHERFR.HTM" TARGET="_top">Inheritance and Object-Oriented Design</A> &nbsp;&nbsp;<BR>&nbsp;&nbsp;Continue to <A HREF="./EI36_FR.HTM" TARGET="_top">Item 36: Differentiate between inheritance of interface and inheritance of implementation.</A></FONT></DIV>

<P><A NAME="dingp1"></A><FONT ID="eititle">Item 35: &nbsp;Make sure public inheritance models "isa."</FONT><SCRIPT>create_link(1);</SCRIPT>
</P>

<A NAME="177826"></A>
<P><A NAME="dingp2"></A>
In his book, <I>Some Must Watch While Some Must Sleep</I> (W. H. Freeman and Company, 1974), William Dement relates the story of his attempt to fix in the minds of his students the most important lessons of his course. It is claimed, he told his class, that the average British schoolchild remembers little more history than that the Battle of Hastings was in 1066. If a child remembers little else, Dement emphasized, he or she remembers the date 1066. For the students in <EM>his</EM> course, Dement went on, there were only a few central messages, including, interestingly enough, the fact that sleeping pills cause insomnia. He implored his students to remember these few critical facts even if they <A NAME="p155"></A>forgot everything else discussed in the course, and he returned to these fundamental precepts repeatedly during the <NOBR>term.<SCRIPT>create_link(2);</SCRIPT>
</NOBR></P>
<A NAME="6920"></A>
<P><A NAME="dingp3"></A>
At the end of the course, the last question on the final exam was, "Write one thing from the course that you will surely remember for the rest of your life." When Dement graded the exams, he was stunned. Nearly everyone had written <NOBR>"1066."<SCRIPT>create_link(3);</SCRIPT>
</NOBR></P>
<A NAME="6921"></A>
<P><A NAME="dingp4"></A>
It is thus with great trepidation that I proclaim to you now that the single most important rule in object-oriented programming with C++ is this: public inheritance means "isa." Commit this rule to <NOBR>memory.<SCRIPT>create_link(4);</SCRIPT>
</NOBR></P>
<A NAME="6923"></A>
<P><A NAME="dingp5"></A>
If you write that class D ("Derived") publicly inherits from class B ("Base"), you are telling C++ compilers (as well as human readers of your code) that every object of type D is also an object of type B, but <I>not vice versa</I>. You are saying that B represents a more general concept than D, that D represents a more specialized concept than B. You are asserting that anywhere an object of type B can be used, an object of type D can be used just as well, because every object of type D <i>is</i> an object of type B. On the other hand, if you need an object of type D, an object of type B will not do: every D isa B, but not vice <NOBR>versa.<SCRIPT>create_link(5);</SCRIPT>
</NOBR></P>
<A NAME="6926"></A>
<P><A NAME="dingp6"></A>
C++ enforces this interpretation of public inheritance. Consider this <NOBR>example:<SCRIPT>create_link(6);</SCRIPT>
</NOBR></P>
<A NAME="6927"></A>
<UL><PRE>class Person { ... };
</PRE>
</UL><A NAME="6928"></A>
<UL><PRE>class Student: public Person { ... };
</PRE>
</UL><A NAME="6929"></A>
<P><A NAME="dingp7"></A>
We know from everyday experience that every student is a person, but not every person is a student. That is exactly what this hierarchy asserts. We expect that anything that is true of a person &#151; for example, that he or she has a date of birth &#151; is also true of a student, but we do not expect that everything that is true of a student &#151; that he or she is enrolled in a particular school, for instance &#151; is true of people in general. The notion of a person is more general than is that of a student; a student is a specialized type of <NOBR>person.<SCRIPT>create_link(7);</SCRIPT>
</NOBR></P>
<A NAME="6930"></A>
<P><A NAME="dingp8"></A>
Within the realm of C++, any function that expects an argument of type <CODE>Person</CODE> (or pointer-to-<CODE>Person</CODE> or reference-to-<CODE>Person</CODE>) will instead take a <CODE>Student</CODE> object (or pointer-to-<CODE>Student</CODE> or reference-to-<CODE>Student</CODE>):<SCRIPT>create_link(8);</SCRIPT>
</P>
<A NAME="6931"></A>
<UL><PRE>
void dance(const Person&amp; p);        // anyone can dance
</PRE>
</UL><A NAME="6932"></A>
<UL><PRE>
void study(const Student&amp; s);       // only students study
</PRE>
</UL><A NAME="6933"></A>
<UL><PRE>
Person p;                           // p is a Person
Student s;                          // s is a Student
</PRE>
</UL><A NAME="6934"></A>
<UL><PRE>
dance(p);                           // fine, p is a Person
</PRE>
</UL><A NAME="6935"></A>
<UL><PRE><A NAME="p156"></A>
dance(s);                           // fine, s is a Student,
                                    // and a Student isa Person
</PRE>
</UL><A NAME="6936"></A>
<UL><PRE>
study(s);                           // fine
</PRE>
</UL><A NAME="6937"></A>
<UL><PRE>
study(p);                           // error! p isn't a Student
</PRE>
</UL><A NAME="6938"></A>
<P><A NAME="dingp9"></A>
This is true only for <I>public</I> inheritance. C++ will behave as I've described only if <CODE>Student</CODE> is publicly derived from <CODE>Person</CODE>. Private inheritance means something entirely different (see <A HREF="./EI42_FR.HTM#21052" TARGET="_top">Item 42</A>), and no one seems to know what protected inheritance is supposed to mean. Furthermore, the fact that a <CODE>Student</CODE> isa <CODE>Person</CODE> does <I>not</I> mean that an <I>array</I> of <CODE>Student</CODE> isa <I>array</I> of <CODE>Person</CODE>. For more information on that topic, see <A HREF="../MEC/MI3_FR.HTM#84818" TARGET="_top">Item M3</A>.<SCRIPT>create_link(9);</SCRIPT>
</P>
<A NAME="6943"></A>
<P><A NAME="dingp10"></A>
The equivalence of public inheritance and isa sounds simple, but in practice, things aren't always so straightforward. Sometimes your intuition can mislead you. For example, it is a fact that a penguin is a bird, and it is a fact that birds can fly. If we naively try to express this in C++, our effort <NOBR>yields:<SCRIPT>create_link(10);</SCRIPT>
</NOBR></P>
<A NAME="6945"></A>
<UL><PRE>class Bird {
public:
  virtual void fly();               // birds can fly
</PRE>
</UL><A NAME="21915"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="21914"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="6949"></A>
<UL><PRE>
class Penguin:public Bird {      // penguins are birds
</PRE>
</UL><A NAME="21916"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="21917"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="6950"></A>
<P><A NAME="dingp11"></A>
Suddenly we are in trouble, because this hierarchy says that penguins can fly, which we know is not true. What <NOBR>happened?<SCRIPT>create_link(11);</SCRIPT>
</NOBR></P>
<A NAME="6951"></A>
<P><A NAME="dingp12"></A>
In this case, we are the victims of an imprecise language (English). When we say that birds can fly, we don't really mean that <I>all</I> birds can fly, only that, in general, birds have the ability to fly. If we were more precise, we'd recognize that there are in fact several types of non-flying birds, and we would come up with the following hierarchy, which models reality much <NOBR>better:<SCRIPT>create_link(12);</SCRIPT>
</NOBR></P>
<A NAME="6953"></A>
<UL><PRE>class Bird {
  ...                   // no fly function is
};                      // declared
</PRE>
</UL><A NAME="6956"></A>
<UL><PRE>class FlyingBird: public Bird {
public:
  virtual void fly();
  ...
};
</PRE>
</UL><A NAME="19658"></A>
<UL><PRE><A NAME="p157"></A>class NonFlyingBird: public Bird {
</PRE>
</UL><A NAME="19661"></A>
<UL><PRE>
  ...                  // no fly function is
                       // declared
};
</PRE>
</UL><A NAME="19660"></A>
<UL><PRE>class Penguin: public NonFlyingBird {
</PRE>
</UL><A NAME="6964"></A>
<UL><PRE>
  ...                  // no fly function is
                       // declared
};
</PRE>
</UL><A NAME="6965"></A>
<P><A NAME="dingp13"></A>
This hierarchy is much more faithful to what we really know than was the original <NOBR>design.<SCRIPT>create_link(13);</SCRIPT>
</NOBR></P>
<A NAME="222334"></A>
<P><A NAME="dingp14"></A>
Even now we're not entirely finished with these fowl matters, because for some software systems, it may be entirely appropriate to say that a penguin is a bird. In particular, if your application has much to do with beaks and wings and nothing to do with flying, the original hierarchy might work out just fine. Irritating though this may seem, it's a simple reflection of the fact that there is no one ideal design for all software. The best design depends on what the system is expected to do, both now and in the future (see <A HREF="../MEC/MI32_FR.HTM#5373" TARGET="_top">Item M32</A>). If your application has no knowledge of flying and isn't expected to ever have any, making <CODE>Penguin</CODE> a derived class of <CODE>Bird</CODE> may be a perfectly valid design decision. In fact, it may be preferable to a decision that makes a distinction between flying and non-flying birds, because such a distinction would be absent from the world you are trying to model. Adding superfluous classes to a hierarchy can be just as bad a design decision as having the wrong inheritance relationships between <NOBR>classes.<SCRIPT>create_link(14);</SCRIPT>
</NOBR></P>
<A NAME="6967"></A>
<P><A NAME="dingp15"></A>
There is another school of thought on how to handle what I call the "All birds can fly, penguins are birds, penguins can't fly, uh oh" problem. That is to redefine the <CODE>fly</CODE> function for penguins so that it generates a runtime <NOBR>error:<SCRIPT>create_link(15);</SCRIPT>
</NOBR></P>
<A NAME="6969"></A>
<UL><PRE>void error(const string&amp; msg);      // defined elsewhere
</PRE>
</UL><A NAME="6971"></A>
<UL><PRE>class Penguin: public Bird {
public:
  virtual void fly() { error("Penguins can't fly!"); }
</PRE>
</UL><A NAME="6972"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="6973"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="6975"></A>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -