📄 ec6.htm
字号:
<!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 | Chapter 6: Inheritance and Object-Oriented Design</TITLE>
<LINK REL=STYLESHEET HREF=../INTRO/ECMEC.CSS>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/COOKIE.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">var imagemax = 11; setCurrentMax(11);</SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/IMGDOC.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/NSIMGDOC.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/DINGBATS.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">
var dingbase = "EC6_DIR.HTM";
var dingtext = "EC++ Inheritance/OOD, P";
if (self == top) {
top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- ten images occurring in Chapter 6 -->
<!-- SectionName="EC++ Chapter Intro: Inheritance and OOD" -->
<A NAME="6898"></A><A NAME="6896"></A><A NAME="p153"></A><A NAME="6895"></A><DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EC5_FR.HTM#6793" TARGET="_top">Item 34: Minimize compilation dependencies between files.</A>
<BR>Continue to <A HREF="#6914">Item 35: Make sure public inheritance models "isa."</A></FONT></DIV>
<P><A NAME="dingp1"></A><FONT ID="egtitle">Inheritance and Object-Oriented Design</FONT><SCRIPT>create_link(1);</SCRIPT>
</P>
<P><A NAME="dingp2"></A>
Many people are of the opinion that inheritance is what object-oriented programming is all about. Whether that's so is debatable, but the number of Items in the other sections of this book should convince you that as far as effective C++ programming is concerned, you have a lot more tools at your disposal than simply specifying which classes inherit from which other <NOBR>classes.<SCRIPT>create_link(2);</SCRIPT>
</NOBR></P>
<A NAME="6899"></A>
<P><A NAME="dingp3"></A>
Still, designing and implementing class hierarchies is fundamentally different from anything found in the world of C. Certainly it is in the area of inheritance and object-oriented design that you are most likely to radically rethink your approach to the construction of software systems. Furthermore, C++ provides a bewildering assortment of object-oriented building blocks, including public, protected, and private base classes; virtual and nonvirtual base classes; and virtual and nonvirtual member functions. Each of these features interacts not only with one another, but also with the other components of the language. As a result, trying to understand what each feature means, when it should be used, and how it is best combined with the non-object-oriented aspects of C++ can be a daunting <NOBR>endeavor.<SCRIPT>create_link(3);</SCRIPT>
</NOBR></P>
<A NAME="6900"></A>
<P><A NAME="dingp4"></A>
Further complicating the matter is the fact that different features of the language appear to do more or less the same thing. <NOBR>Examples:<SCRIPT>create_link(4);</SCRIPT>
</NOBR></P>
<UL><A NAME="6901"></A>
<A NAME="dingp5"></A><LI>You need a collection of classes with many shared characteristics. Should you use inheritance and have all the classes derived from a common base class, or should you use templates and have them all generated from a common code skeleton?<SCRIPT>create_link(5);</SCRIPT>
<A NAME="6902"></A>
<A NAME="dingp6"></A><LI>Class A is to be implemented in terms of class B. Should A have a data member of type B, or should A privately inherit from B?<SCRIPT>create_link(6);</SCRIPT>
<A NAME="6903"></A>
<A NAME="dingp7"></A><LI><A NAME="p154"></A>You need to design a type-safe homogeneous container class, one not present in the standard library. (See <A HREF="./EC7_FR.HTM#8392" TARGET="_top">Item 49</A> for a list of containers the library <I>does</I> provide.) Should you use templates, or would it be better to build type-safe interfaces around a class that is itself implemented using generic (<CODE>void*</CODE>) pointers?<SCRIPT>create_link(7);</SCRIPT>
</UL>
<A NAME="6904"></A>
<P><A NAME="dingp8"></A>
In the Items in this section, I offer guidance on how to answer questions such as these. However, I cannot hope to address every aspect of object-oriented design. Instead, I concentrate on explaining what the different features in C++ really <I>mean</I>, on what you are really <I>saying</I> when you use a particular feature. For example, public inheritance means "isa" (see <A HREF="#6914">Item 35</A>), and if you try to make it mean anything else, you will run into trouble. Similarly, a virtual function means "interface must be inherited," while a nonvirtual function means "both interface <I>and</I> implementation must be inherited." Failing to distinguish between these meanings has caused many a C++ programmer untold <NOBR>grief.<SCRIPT>create_link(8);</SCRIPT>
</NOBR></P>
<A NAME="6908"></A>
<P><A NAME="dingp9"></A>
If you understand the meanings of C++'s varied features, you'll find that your outlook on object-oriented design shifts. Instead of it being an exercise in differentiating between language constructs, it will properly become a matter of figuring out what it is you want to say about your software system. Once you know what you want to say, you'll be able to translate that into the appropriate C++ features without too much <NOBR>difficulty.<SCRIPT>create_link(9);</SCRIPT>
</NOBR></P>
<A NAME="6909"></A>
<P><A NAME="dingp10"></A>
The importance of saying what you mean and understanding what you're saying cannot be overestimated. The items that follow provide a detailed examination of how to do this effectively. <A HREF="#8113">Item 44</A> summarizes the correspondence between C++'s object-oriented constructs and what they mean. It serves as a nice capstone for this section, as well as a concise reference for future <NOBR>consultation.<SCRIPT>create_link(10);</SCRIPT>
</NOBR></P>
<!-- SectionName="E35: Make sure public inheritance models 'isa'" -->
<A NAME="6914"></A><A NAME="177826"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#6895">Inheritance and Object-Oriented Design</A>
<BR>Continue to <A HREF="#7007">Item 36: Differentiate between inheritance of interface and inheritance of implementation.</A></FONT></DIV>
<P><A NAME="dingp11"></A><FONT ID="eititle">Item 35: Make sure public inheritance models "isa."</FONT><SCRIPT>create_link(11);</SCRIPT>
</P>
<P><A NAME="dingp12"></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(12);</SCRIPT>
</NOBR></P>
<A NAME="6920"></A>
<P><A NAME="dingp13"></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(13);</SCRIPT>
</NOBR></P>
<A NAME="6921"></A>
<P><A NAME="dingp14"></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(14);</SCRIPT>
</NOBR></P>
<A NAME="6923"></A>
<P><A NAME="dingp15"></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(15);</SCRIPT>
</NOBR></P>
<A NAME="6926"></A>
<P><A NAME="dingp16"></A>
C++ enforces this interpretation of public inheritance. Consider this <NOBR>example:<SCRIPT>create_link(16);</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="dingp17"></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 — for example, that he or she has a date of birth — is also true of a student, but we do not expect that everything that is true of a student — that he or she is enrolled in a particular school, for instance — 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(17);</SCRIPT>
</NOBR></P>
<A NAME="6930"></A>
<P><A NAME="dingp18"></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(18);</SCRIPT>
</P>
<A NAME="6931"></A>
<UL><PRE>
void dance(const Person& p); // anyone can dance
</PRE>
</UL><A NAME="6932"></A>
<UL><PRE>
void study(const Student& 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="dingp19"></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="#21052">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/MC1_FR.HTM#84818" TARGET="_top">Item M3</A>.<SCRIPT>create_link(19);</SCRIPT>
</P>
<A NAME="6943"></A>
<P><A NAME="dingp20"></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(20);</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="dingp21"></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(21);</SCRIPT>
</NOBR></P>
<A NAME="6951"></A>
<P><A NAME="dingp22"></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(22);</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="dingp23"></A>
This hierarchy is much more faithful to what we really know than was the original <NOBR>design.<SCRIPT>create_link(23);</SCRIPT>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -