Inheritance and Class Hierarchies

A C++ program works with types. Every value and every object in a program belongs to some type, and the type tells the program what kind of thing it is dealing with. Some types come with the language itself. The built-in number types are the standard example. Programmers do not write those types; they simply use them.

Real programs, however, deal with ideas that the language cannot know about in advance: a bank account, a shape, a sensor reading. C++ lets you define new types of your own for exactly this purpose. These are called user-defined types. A user-defined type lets you model one idea from your problem as a single named type in your program. Once you have that named type, the rest of the program can talk about bank accounts, shapes, or sensor readings directly instead of juggling loose collections of numbers.

This article follows one idea through a short sequence: first, how user-defined types differ from built-in ones; then, the two basic families of user-defined types, concrete classes and abstract classes; and finally, how related types are arranged into a class hierarchy through inheritance. At each stage you will check a claim against a concrete picture before moving on.

The difference between the two kinds of type comes down to where the definition comes from. A built-in type is supplied by the language itself, such as the built-in number types. A user-defined type is one the programmer defines, so the programmer decides what the type represents and what it is named.

The key test for a concrete class is simple: can you make an object from it? If the answer is yes, the class is concrete. Most of the classes you write to represent a single, complete idea in your program are concrete. When you create an object from a concrete class, the object is an actual instance of that type, ready to hold data and respond to the operations the class defines.

The contrast with a concrete class is the important part. A concrete class answers the question can I create an object of this type with yes. An abstract class answers it with no. You do not create objects from the abstract class itself. Instead, you create objects from the classes that inherit from it, because those are the classes that describe complete things.

Keep the two columns in the diagram apart in your mind. The same question, whether an object can be created from this class, produces yes for a concrete class and no for an abstract class.

A class hierarchy gives related types a shared structure. A general class sits near the top, and more specific classes sit below it, each inheriting from the class above it. Read the hierarchy from the top down and each step adds specificity. Read it from the bottom up and each step generalizes.

Work through the small example below, which is a generated illustration of this idea. Shape is the general idea. Circle, Square, and Triangle are the specific kinds of shape, and each inherits from Shape. Trace the links from the top: the three specific classes all sit one level below Shape, and each one is connected to it by an inheritance link.

Notice what the diagram does and does not say. It shows that Circle, Square, and Triangle inherit from Shape. It does not, by itself, tell you whether Shape can have objects created from it. That is a separate question, and you answer it by applying the can-I-create-it test from the previous sections. The source notes that abstract classes often appear near the top of a hierarchy because they describe what the related classes have in common, while concrete classes often appear at the bottom, where complete objects are created. The word often matters: position in the hierarchy is a hint, not a proof.