This Exploration takes a break from C++ programming to turn to the topic of object-oriented programming (OOP). You may already be familiar with this topic, but I urge you to continue reading. You may learn something new. To everyone else, this Exploration introduces some of the foundations of OOP in general terms. Later Explorations will show how C++ implements OOP principles.

Books and Magazines

What is the difference between a book and a magazine? Yes, I really want you to write down your answer. Write down as many differences as you can think of.

What are the similarities between books and magazines? Write down as many similarities as you can think of.

If you can, compare your lists with the lists that other people write. They don’t have to be programmers; everyone knows what books and magazines are. Ask your friends and neighbors; stop strangers at the bus stop and ask them. Try to find a core set of commonalities and differences.

Many items on the lists will be qualified. For instance, “most books have at least one author,” “many magazines are published monthly,” and so on. That’s fine. When solving real problems, we often map “maybe” and “sometimes” into “never” or “always,” according to the specific needs of the problem at hand. Just remember that this is an OOP exercise, not a bookstore or library exercise.

Now categorize the commonalities and the differences. I’m not telling you how to categorize them. Just try to find a small set of categories that covers the diverse items on your lists. Some less useful categorizations are: group by number of words, group by last letter. Try to find useful categories. Write them down.

I came up with two broad categories: attributes and actions. Attributes describe the physical characteristics of books and magazines.

• Books and magazines have size (number of pages) and cost.
• Most books have an ISBN (International Standard Book Number).
• Most magazines have an ISSN (International Standard Serial Number).
• Magazines have a volume number and issue number.

Books and magazines have a title and publisher. Books have authors. Magazines typically don’t. (Magazine articles have authors, but a magazine as a whole rarely lists an author.)

Actions describe how a book or magazine acts or how you interact with them.

• You can read a book or magazine. A book or magazine can be open or closed.
• You can purchase a book or magazine.
• You can subscribe to a magazine.

The key distinction between attributes and actions is that attributes are specific to a single object. Actions are shared by all objects of a common class. Sometimes, actions are called behaviors. All dogs exhibit the behavior called panting; they all pant in pretty much the same manner and for the same reasons. All dogs have the attribute color, but one dog is golden, another dog is black, and the dog over there next to the tree is white with black spots.

In programming terms, a class describes the behaviors or actions and the types of attributes for all the objects of that class. Each object has its own values for the attributes that the class enumerates. In C++ terms, member functions implement actions and provide access to attributes, and data members store attributes.

Classification

Books and magazines don’t do much on their own. Instead, their “actions” depend on how we interact with them. A bookstore interacts with books and magazines by selling, stocking, and advertising them. A library’s actions include lending and accepting returns. Other kinds of objects have actions they initiate on their own. For example, what are some of the behaviors of a dog?

What are the attributes of a dog?

What about a cat? Do cats and dogs have significantly different behaviors? ____________ Attributes? ________________ Summarize the differences.

I don’t own dogs or cats, so my observations are limited. From where I sit, dogs and cats have many similar attributes and behaviors. I expect that many readers are much more astute observers than I and can enumerate quite a few differences between the two animals.

Nonetheless, I maintain that once you consider the differences closely, you will see that many of them are not attributes or behaviors unique to one type of animal or the other but are merely different values of a single attribute or different details of a single behavior. Cats may be more fastidious, but dogs and cats both exhibit grooming behavior. Dogs and cats come in different colors, but they both have colored furs (with rare exceptions).

In other words, when trying to enumerate the attributes and behaviors of various objects, your job can be made simpler by classifying similar objects together. For critters, biologists have already done the hard work for us, and they have devised a rich and detailed taxonomy of animals. Thus, a species (catus or familiaris) belongs to a genus (Felis or Canis), which is part of a family (Felidae or Canidae). These are grouped yet further into an order (Carnivora), a class (Mammalia), and so on, up to the animal (Metazoa) kingdom. (Taxonomists: Please forgive my oversimplification.)

So what happens to attributes and behaviors as you ascend the taxonomic tree? Which attributes and behaviors are the same across all mammals?

All animals?

As the classification became broader, the attributes and behavior also became more general. Among the attributes of dogs and cats are color of fur, length of tail, weight, and much more. Not all mammals have fur or tails, so you need broader attributes for the entire class. Weight still works, but instead of overall length, you may want to use size. Instead of color of fur, you need only generic coloring. For all animals, the attributes are quite broad: size, weight, single-cell vs. multicell, etc.

Behaviors are similar. You may list that cats purr, dogs pant, both animals can walk and run, and so on. All mammals eat and drink. Female mammals nurse their young. For all animals, you are left with a short, general list: eat and reproduce. It’s hard to be more specific than that when you are trying to list the behaviors common to all animals, from amoebae to zebras.

A classification tree helps biologists understand the natural world. Class trees (or class hierarchies, as they are often called, because big words make us feel important) help programmers model the natural world in software (or model the unnatural world, as so often happens in many of our projects). Instead of trying to name each level of the tree, programmers prefer a local, recursive view of any class hierarchy. Going up the tree, each class has a base class, also called a superclass or parent class. Thus animal is a base class of mammal, which is a base class of dog. Going downward are derived classes, also called subclasses or child classes. Dog is a derived class of mammal. Figure 36-1 illustrates a class hierarchy. Arrows point from derived class to base class.

An immediate base class is one with no intervening base classes. For example, the immediate base class of catus is Felis, which has an immediate base class of Felidae, which has an immediate base class of Carnivora. Metazoa, Mammalia, Carnivora, Felidae, and Felis are all base classes of catus, but only Felis is its immediate base class.

Inheritance

Just as a mammal has all the attributes and behaviors of an animal, and a dog has the attributes and behaviors of all mammals, in an OOP language, a derived class has all the behaviors and attributes of all of its base classes. The term most often used is inheritance: the derived class inherits the behaviors and attributes of its base class. This term is somewhat unfortunate, because OOP inheritance is nothing like real-world inheritance. When a derived class inherits behaviors, the base class retains its behaviors. In the real world, classes don’t inherit anything; objects do.

In the real world, a person object inherits the value of certain attributes (cash, stock, real estate, etc.) from a deceased ancestor object. In the OOP world, a person class inherits behaviors from a base class, such as primate, by sharing the single copy of those behavior functions that are defined in the base class. A person class inherits the attributes of a base class, so objects of the derived class contain values for all the attributes defined in its class and in all of its base classes. In time, the inheritance terminology will become natural to you.

Because inheritance creates a tree structure, tree terminology also pervades discussion of inheritance. As is so common in programming, tree diagrams are drawn upside down, with the root at the top, and leaves at the bottom (as you saw in Figure 36-1). Some OOP languages (Java, Smalltalk, Delphi) have a single root, which is the ultimate base class for all classes. Others, such as C++, do not. Any class can be the root of its own inheritance tree.

So far, the main examples for inheritance involved some form of specialization. Cat is more specialized than mammal, which is more specialized than animal. The same is true in computer programming. For example, class frameworks for graphical user interfaces (GUIs) often use a hierarchy of specialized classes. Figure 36-2 shows a selection of some of the more important classes that make up wxWidgets, which is an open-source C++ framework that supports many platforms.

Even though C++ does not require a single root class, some frameworks do; wxWidgets is one that does require a single root class. Most wxWidgets classes derive from wxObject. Some objects are straightforward, such as wxPen and wxBrush. Interactive objects derive from wxEvtHandler (short for “event handler”). Thus, each step in the class tree introduces another degree of specialization.

Later in the book, you will see other uses for inheritance, but the most common and most important use is to create specialized derived classes from more general base classes.

Liskov’s Substitution Principle

When a derived class specializes the behavior and attributes of a base class (which is the common case), any code that you write involving the base class should work equally well with an object of the derived class. In other words, the act of feeding a mammal is, in broad principles, the same, regardless of the specific kind of animal.

Barbara Liskov and Jeannette Wing formalized this fundamental principle of object-oriented programming, which is often known today as the Substitution Principle or Liskov’s Substitution Principle. Briefly, the Substitution Principle states that if you have base class B and derived class D, in any situation that calls for an object of type B, you can substitute an object of type D, with no ill effects. In other words, if you need a mammal, any mammal, and someone hands you a dog, you should be able to use that dog. If someone hands you a cat, a horse, or a cow, you can use that animal. If someone hands you a fish, however, you are allowed to reject the fish in any manner that you deem suitable.

The Substitution Principle helps you write programs, but it also imposes a burden. It helps because it frees you to write code that depends on base class behavior without concerning yourself about any derived classes. For example, in a GUI framework, the base wxEvtHandler class might be able to recognize a mouse click and dispatch it to an event handler. The click handler does not know or care whether the control is actually a wxListCtrl control, a wxTreeCtrl control, or a wxButton. All that matters is that wxEvtHandler accepts a click event, acquires the position, determines which mouse button was clicked, and so on, and then dispatches this event to the event handler.

The burden is on the authors of the wxButton, wxListCtrl, and wxTreeCtrl classes to ensure that their click behavior meets the requirements of the Substitution Principle. The easiest way to meet the requirements is to let the derived class inherit the behavior of the base class. Sometimes, however, the derived class has additional work to do. Instead of inheriting, it provides new behavior. In that case, the programmer must ensure that the behavior is a valid substitution for the base class behavior. The next few Explorations will show concrete examples of this abstract principle.

Type Polymorphism

Before returning to C++-land, I want to present one more general principle. Suppose I hand you a box labeled “Mammal.” Inside the box can be any mammal: a dog, a cat, a person, etc. You know the box cannot contain a bird, a fish, a rock, or a tree. It must contain a mammal. Programmers call the box polymorphic, from the Greek meaning “many forms.” The box can hold any one of many forms, that is, any one mammal, regardless of which form of mammal it is.

Although many programmers use the general term polymorphism, this specific kind of polymorphism is type polymorphism, also known as subtyping polymorphism. That is, the type of a variable (or a box) determines which kinds of objects it can contain. A polymorphic variable (or box) can contain one of a number of types of objects.

In particular, a variable with a base class type can refer to an object of the base class type or to an object of any type that is derived from that base class. According to the Substitution Principle, you can write code to use the base class variable, calling any of the member functions of the base class, and that code will work, regardless of the object’s true, derived type.

Now that you have a fundamental understanding of the principles of OOP, it is time to see how they play out in C++.