ec6.htm

一个非常适合初学者入门的有关c++的文档

</NOBR></P>
<A NAME="222334"></A>
<P><A NAME="dingp24"></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 isa 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/MC6_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(24);</SCRIPT>
</NOBR></P>
<A NAME="6967"></A>
<P><A NAME="dingp25"></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(25);</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>
<P><A NAME="dingp26"></A>
Interpreted languages such as Smalltalk tend to adopt this approach, but it's important to recognize that this says something entirely different from what you might think. This does <I>not</I> say, "Penguins can't fly." This says, "Penguins can fly, but it's an error for them to try to do <NOBR>so."<SCRIPT>create_link(26);</SCRIPT>
</NOBR></P>
<A NAME="6976"></A>
<P><A NAME="dingp27"></A>
<A NAME="p158"></A>How can you tell the difference? From the time at which the error is detected. The injunction, "Penguins can't fly," can be enforced by compilers, but violations of the statement, "It's an error for penguins to try to fly," can be detected only at <NOBR>runtime.<SCRIPT>create_link(27);</SCRIPT>
</NOBR></P>
<A NAME="6977"></A>
<P><A NAME="dingp28"></A>
To express the constraint, "Penguins can't fly," you make sure that no such function is defined for <CODE>Penguin</CODE> <NOBR>objects:<SCRIPT>create_link(28);</SCRIPT>
</NOBR></P>
<A NAME="6979"></A>
<UL><PRE>class Bird {
</PRE>
</UL><A NAME="6980"></A>
<UL><PRE>
  ...                          // no fly function is
                               // declared
};
</PRE>
</UL><A NAME="6982"></A>
<UL><PRE>class NonFlyingBird: public Bird {
</PRE>
</UL><A NAME="6983"></A>
<UL><PRE>
  ...                          // no fly function is
                               // declared
};
</PRE>
</UL><A NAME="6985"></A>
<UL><PRE>class Penguin: public NonFlyingBird {
</PRE>
</UL><A NAME="6986"></A>
<UL><PRE>
  ...                          // no fly function is
                               // declared
};
</PRE>
</UL><A NAME="6987"></A>
<P><A NAME="dingp29"></A>
If you try to make a penguin fly, compilers will reprimand you for your <NOBR>transgression:<SCRIPT>create_link(29);</SCRIPT>
</NOBR></P>
<A NAME="6988"></A>
<UL><PRE>Penguin p;
</PRE>
</UL><A NAME="6989"></A>
<UL><PRE>
p.fly();                       // error!
</PRE>
</UL><A NAME="6991"></A>
<P><A NAME="dingp30"></A>
This is very different from the behavior you get if you use the Smalltalk approach. With that methodology, compilers won't say a <NOBR>word.<SCRIPT>create_link(30);</SCRIPT>
</NOBR></P>
<A NAME="6993"></A>
<P><A NAME="dingp31"></A>
The C++ philosophy is fundamentally different from the Smalltalk philosophy, so you're better off doing things the C++ way as long as you're programming in C++. In addition, there are certain technical advantages to detecting errors during compilation instead of at runtime &#151; see <A HREF="./EC7_FR.HTM#195225" TARGET="_top">Item 46</A>.<SCRIPT>create_link(31);</SCRIPT>
</P>
<A NAME="29669"></A>
<P><A NAME="dingp32"></A>
Perhaps you'll concede that your ornithological intuition may be lacking, but you can rely on your mastery of elementary geometry, right? I mean, how complicated can rectangles and squares <NOBR>be?<SCRIPT>create_link(32);</SCRIPT>
</NOBR></P>
<A NAME="29670"></A>
<P><A NAME="dingp33"></A>
Well, answer this simple question: should class <CODE>Square</CODE> publicly inherit from class <CODE>Rectangle</CODE>?<SCRIPT>create_link(33);</SCRIPT>
</P>

<SPAN ID="Image1of1" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A1.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of2" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A2.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of3" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A3.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of4" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A4.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of5" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A5.GIF" BORDER=0></SPAN>

<SPAN ID="Image1of6" STYLE="position: relative; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_158A5.GIF" BORDER=0></SPAN>

<A NAME="19898"></A>
<P><A NAME="dingp34"></A>
"<A NAME="p159"></A>Duh!" you say, "Of course it should! Everybody knows that a square is a rectangle, but generally not vice versa." True enough, at least in high school. But I don't think we're in high school <NOBR>anymore.<SCRIPT>create_link(34);</SCRIPT>
</NOBR></P>
<A NAME="19952"></A>
<A NAME="dingp35"></A>Consider this code:<SCRIPT>create_link(35);</SCRIPT>

<A NAME="19922"></A>
<UL><PRE>class Rectangle {
public:
  virtual void setHeight(int newHeight);
  virtual void setWidth(int newWidth);
</PRE>
</UL><A NAME="19923"></A>
<UL><PRE>
  virtual int height() const;          // return current
  virtual int width() const;           // values
</PRE>
</UL><A NAME="19924"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="19925"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="19926"></A>
<UL><PRE>
void makeBigger(Rectangle&amp; r)          // function to
{                                      // increase r's area
  int oldHeight = r.height();
</PRE>
</UL><A NAME="19927"></A>
<UL><PRE>
  r.setWidth(r.width() + 10);          // add 10 to r's width
</PRE>
</UL><A NAME="19928"></A>
<UL><PRE>
  assert(r.height() == oldHeight);     // assert that r's
}                                      // height is unchanged
</PRE>
</UL><A NAME="19929"></A>
<P><A NAME="dingp36"></A>
Clearly, the assertion should never fail. <CODE>makeBigger</CODE> only changes <CODE>r</CODE>'s width. Its height is never <NOBR>modified.<SCRIPT>create_link(36);</SCRIPT>
</NOBR></P>
<A NAME="19935"></A>
<P><A NAME="dingp37"></A>
Now consider this code, which uses public inheritance to allow squares to be treated like <NOBR>rectangles:<SCRIPT>create_link(37);</SCRIPT>
</NOBR></P>
<A NAME="19936"></A>
<UL><PRE>class Square: public Rectangle { ... };
</PRE>
</UL><A NAME="19970"></A>
<UL><PRE>Square s;
</PRE>
</UL><A NAME="19940"></A>
<UL><PRE>...
</PRE>
</UL><A NAME="19963"></A>
<UL><PRE>
assert(s.width() == s.height());      // this must be true
                                      // for all squares
</PRE>
</UL><A NAME="19941"></A>
<UL><PRE>
makeBigger(s);                        // by inheritance, s
                                      // isa Rectangle, so
                                      // we can increase its
                                      // area
</PRE>
</UL><A NAME="19942"></A>
<UL><PRE>
assert(s.width() == s.height());      // this must still be
                                      // true for all squares
</PRE>
</UL><A NAME="19943"></A>
<P><A NAME="dingp38"></A>
It's just as clear here as it was above that this last assertion should also never fail. By definition, the width of a square is the same as its <NOBR>height.<SCRIPT>create_link(38);</SCRIPT>
</NOBR></P>
<A NAME="19961"></A>
<P><A NAME="dingp39"></A>
<A NAME="p160"></A>But now we have a problem. How can we reconcile the following <NOBR>assertions?<SCRIPT>create_link(39);</SCRIPT>
</NOBR></P><UL><A NAME="19989"></A>
<P><A NAME="dingp40"></A><LI>Before calling <CODE>makeBigger</CODE>, <CODE>s</CODE>'s height is the same as its width;<SCRIPT>create_link(40);</SCRIPT>

<A NAME="19990"></A>
<P>
<A NAME="dingp41"></A><LI>Inside <CODE>makeBigger</CODE>, <CODE>s</CODE>'s width is changed, but its height is not;<SCRIPT>create_link(41);</SCRIPT>

<A NAME="20013"></A>
<P>
<A NAME="dingp42"></A><LI>After returning from <CODE>makeBigger</CODE>, <CODE>s</CODE>'s height is again the same as its width. (Note that <CODE>s</CODE> is passed to <CODE>makeBigger</CODE> by reference, so <CODE>makeBigger</CODE> modifies <CODE>s</CODE> itself, not a copy of <CODE>s</CODE>.)<SCRIPT>create_link(42);</SCRIPT>

</UL></P>
<A NAME="20014"></A>
<A Name="dingp43"></A><NOBR>Well?<SCRIPT>create_link(43);</SCRIPT>
</NOBR></P>
<A NAME="29700"></A>
<P><A NAME="dingp44"></A>
Welcome to the wonderful world of public inheritance, where the instincts you've developed in other fields of study &#151; including mathematics &#151; may not serve you as well as you expect. The fundamental difficulty in this case is that something applicable to a rectangle (its width may be modified independently of its height) is not applicable to a square (its width and height are constrained to be the same). But public inheritance asserts that everything applicable to base class objects &#151; <I>everything!</I> &#151; is also applicable to derived class objects. In the case of rectangles and squares (and a similar example involving sets and lists in <A HREF="#7424">Item 40</A>), that assertion fails to hold, so using public inheritance to model their relationship is just plain wrong. Compilers will let you do it, of course, but as we've just seen, that's no guarantee the code will behave properly. As every programmer must learn (some more often than others), just because the code compiles doesn't mean it will <NOBR>work.<SCRIPT>create_link(44);</SCRIPT>
</NOBR></P>
<A NAME="20052"></A>
<P><A NAME="dingp45"></A>
Now, don't fret that the software intuition you've developed over the years will fail you as you approach object-oriented design. That knowledge is still valuable, but now that you've added inheritance to your arsenal of design alternatives, you'll have to augment your intuition with new insights to guide you in inheritance's proper application. In time, the notion of having <CODE>Penguin</CODE> inherit from <CODE>Bird</CODE> or <CODE>Square</CODE> inherit from <CODE>Rectangle</CODE> will give you the same funny feeling you probably get now when somebody shows you a function several pages long. It's <I>possible</I> that it's the right way to approach things, it's just not very <NOBR>likely.<SCRIPT>create_link(45);</SCRIPT>
</NOBR></P>
<A NAME="6998"></A>
<P><A NAME="dingp46"></A>
Of course, the isa relationship is not the only one that can exist between classes. Two other common inter-class relationships are "has-a" and "is-implemented-in-terms-of." These relationships are considered in Items <A HREF="#7424">40</A> and <A HREF="#21052">42</A>. It's not uncommon for C++ designs to go awry because one of these other important relationships was incorrectly modeled as isa, so you should make sure that you understand the differences between these relationships and that you know how they are best modeled in <NOBR>C++.<SCRIPT>create_link(46);</SCRIPT>
</NOBR></P>
<!-- SectionName="E36: Interface vs. implementation inheritance" -->