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.
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.
Comments
Post a Comment
https://gengwg.blogspot.com/