24: Inheritance. The Is-A Relationship.

Class relationships bring out the full power of object-oriented programming. Inheritance allows you to create classes that specialize or extend other classes. You can create entire hierarchies of classes but there are enough gotchas that some languages have restricted inheritance. This episode will not only explain what inheritance is but give you some guidance on how to use it wisely. Let’s say you are modeling books. You might want a class hierarchy that looks like this: Class name: book Base class: none Class name: physicalBook Base class: book Class name: audioBook Base class: book In this case, both the physicalBook and audioBook classes derive from the book class. You can then put all the data and methods that’s common to all books in the book class and then add to that of even modify the book class methods in the derived classes. You can also have multiple levels of inheritance like this: Class name: physicalObject Base class: none Class name: armor Base class: physicalObject Class name: helmet Base class: armor This says that a helmet is an armor and that an armor is a physicalObject. Listen to the full episode or read the full transcript below. Transcript When you’re designing your classes, look for common behavior and once you find it, you can place this common behavior in another class. Let’s call this a base class. You can now reuse that behavior and even the data members that go along with it in other classes without needing to rewrite it all. What you do is declare another class with any special or new behavior as well as the data members that aren’t found in the base class. You then say that this new class derives from the base class. Your new class is a derived class. This is inheritance. The derived class now has all the capabilities of both classes. You can refer to the derived class as either the derived class when you want the more specific and new capabilities or as the base class when you only care about the common capabilities. You can have multiple derived class types that all derive from the same base class but add different behavior. We actually do this all the time in real life. The concept of inheritance is nothing new. It’s actually modeled after our everyday experiences. Want proof? Just look around you. Pick something and describe it. Let’s say you find a couple books. They’re both books but probably look a bit different. Maybe one is a paperback and the other is a hardback. They have different titles and different number of pages and different contents. So far these are all just differences that could be explained with a single class that has different data values. But what about a hardback book vs. an audio book. Now we’re getting some different behavior because you actually need to interact with these books in very different ways. If you need to include the concept of hardback and audio books in your program, then they should probably be different classes. But even with the differences, there’s still a lot of similarity. We refer to them both as books. They both have an author. You can buy or borrow each of them. You can navigate to different chapters. In your software design, you’ll likely want a book class as a base class and a physical book class and an audio book class. This type of categorization applies to other things in our normal experience too. Think about a tree. What is it? It’s a plant. There’s all kinds of behavior that all plants share from trees to grass. It’s also a life form capable of reproducing and dying. That’s shared by other life forms including us. We just have differences in behavior in how we go about these things. It’s also a solid object and shares those properties even with a rock. You can keep going with this but at some point, you have to realize that you’re never going to be able to or even want to model the real world in software down to a level that no longe