ec6.htm

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

 Effective C++, 2E | Chapter 6: Inheritance and Object-Oriented Design Back to Item 34: Minimize compilation dependencies between files.
Continue to Item 35: Make sure public inheritance models "isa."
Inheritance and Object-Oriented Design
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 classes.
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 endeavor.
Further complicating the matter is the fact that different features of the language appear to do more or less the same thing. Examples: 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? 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? You need to design a type-safe homogeneous container class, one not present in the standard library. (See Item 49 for a list of containers the library does provide.) Should you use templates, or would it be better to build type-safe interfaces around a class that is itself implemented using generic (void*) pointers?
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 mean, on what you are really saying when you use a particular feature. For example, public inheritance means "isa" (see Item 35), 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 and implementation must be inherited." Failing to distinguish between these meanings has caused many a C++ programmer untold grief.
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 difficulty.
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. Item 44 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 consultation. Back to Inheritance and Object-Oriented Design
Continue to Item 36: Differentiate between inheritance of interface and inheritance of implementation.
Item 35: Make sure public inheritance models "isa."
In his book, Some Must Watch While Some Must Sleep (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 his 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 forgot everything else discussed in the course, and he returned to these fundamental precepts repeatedly during the term.
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 "1066."
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 memory.
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 not vice versa. 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 is 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 versa.
C++ enforces this interpretation of public inheritance. Consider this example: class Person { ... };

class Student: public Person { ... };


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 person.
Within the realm of C++, any function that expects an argument of type Person (or pointer-to-Person or reference-to-Person) will instead take a Student object (or pointer-to-Student or reference-to-Student): 
void dance(const Person& p);        // anyone can dance


void study(const Student& s);       // only students study


Person p;                           // p is a Person
Student s;                          // s is a Student


dance(p);                           // fine, p is a Person


dance(s);                           // fine, s is a Student,
                                    // and a Student isa Person


study(s);                           // fine


study(p);                           // error! p isn't a Student


This is true only for public inheritance. C++ will behave as I've described only if Student is publicly derived from Person. Private inheritance means something entirely different (see Item 42), and no one seems to know what protected inheritance is supposed to mean. Furthermore, the fact that a Student isa Person does not mean that an array of Student isa array of Person. For more information on that topic, see Item M3.
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 yields: class Bird {
public:
  virtual void fly();               // birds can fly

  ...

};


class Penguin:public Bird {      // penguins are birds

  ...

};


Suddenly we are in trouble, because this hierarchy says that penguins can fly, which we know is not true. What happened?
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 all 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 better: class Bird {
  ...                   // no fly function is
};                      // declared

class FlyingBird: public Bird {
public:
  virtual void fly();
  ...
};

class NonFlyingBird: public Bird {


  ...                  // no fly function is
                       // declared
};

class Penguin: public NonFlyingBird {


  ...                  // no fly function is
                       // declared
};


This hierarchy is much more faithful to what we really know than was the original design.
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 Item M32). If your application has no knowledge of flying and isn't expected to ever have any, making Penguin a derived class of Bird 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 classes.
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 fly function for penguins so that it generates a runtime error: void error(const string& msg);      // defined elsewhere

class Penguin: public Bird {
public:
  virtual void fly() { error("Penguins can't fly!"); }

  ...

};


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 not say, "Penguins can't fly." This says, "Penguins can fly, but it's an error for them to try to do so."
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 runtime.
To express the constraint, "Penguins can't fly," you make sure that no such function is defined for Penguin objects: class Bird {


  ...                          // no fly function is
                               // declared
};

class NonFlyingBird: public Bird {


  ...                          // no fly function is
                               // declared
};

class Penguin: public NonFlyingBird {


  ...                          // no fly function is
                               // declared
};


If you try to make a penguin fly, compilers will reprimand you for your transgression: Penguin p;


p.fly();                       // error!


This is very different from the behavior you get if you use the Smalltalk approach. With that methodology, compilers won't say a word.
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 see Item 46.
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 be?
Well, answer this simple question: should class Square publicly inherit from class Rectangle?
"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 anymore. Consider this code: class Rectangle {
public:
  virtual void setHeight(int newHeight);
  virtual void setWidth(int newWidth);


  virtual int height() const;          // return current
  virtual int width() const;           // values

  ...

};


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


Clearly, the assertion should never fail. makeBigger only changes r's width. Its height is never modified.
Now consider this code, which uses public inheritance to allow squares to be treated like rectangles: class Square: public Rectangle { ... };

Square s;

...