Professional C__ - Marc Gregoire [44]
Adding Properties
A subclass can also add new properties to the ones that were inherited from the superclass. A penguin has all the properties of an animal but also has a beak size property.
Replacing Properties
C++ provides a way of overriding properties similar to the way you can override behaviors. However, doing so is rarely appropriate. It’s important not to get the notion of replacing a property confused with the notion of subclasses having different values for properties. For example, all animals have a diet property that indicates what they eat. Monkeys eat bananas and penguins eat fish, but neither of these is replacing the diet property — they simply differ in the value assigned to the property.
Polymorphism versus Code Reuse
Polymorphism is the notion that objects that adhere to a standard set of properties and behaviors can be used interchangeably. A class definition is like a contract between objects and the code that interacts with them. By definition, any Monkey object must support the properties and behaviors of the Monkey class.
This notion extends to superclasses as well. Because all monkeys are animals, all Monkey objects support the properties and behaviors of the Animal class as well.
Polymorphism is a beautiful part of object-oriented programming because it truly takes advantage of what inheritance offers. In a zoo simulation, you could programmatically loop through all of the animals in the zoo and have each animal move once. Since all animals are members of the Animal class, they all know how to move. Some of the animals have overridden the move behavior, but that’s the best part — our code simply tells each animal to move without knowing or caring what type of animal it is. Each one moves whichever way it knows how.
There is another reason to subclass besides polymorphism. Often, it’s just a matter of leveraging existing code. For example, if you need a class that plays music with an echo effect, and your coworker has already written one that plays music without any effects, you might be able to extend the existing class and add in the new functionality. The is-a relationship still applies (an echo music player is a music player that adds an echo effect), but you didn’t intend for these classes to be used interchangeably. What you end up with are two separate classes, used in completely different parts of the programs (or maybe even in different programs entirely) that happen to be related only to avoid reinventing the wheel.
The Fine Line between Has-A and Is-A
In the real world, it’s pretty easy to classify has-a and is-a relationships between objects. Nobody would claim that an orange has a fruit — an orange is a fruit. In code, things sometimes aren’t so clear.
Consider a hypothetical class that represents a hash table. A hash table is a data structure that efficiently maps a key to a value. For example, an insurance company could use a Hashtable class to map member IDs to names so that given an ID, it’s easy to find the corresponding member name. The member ID is the key and the member name is the value.
In a standard hash table implementation, every key has a single value. If the ID 14534 maps to the member name “Kleper, Scott”, it cannot also map to the member name “Kleper, Marni”. In most implementations, if you tried to add a second value for a key that already has a value, the first value would go away. In other words,