CS101: Inheritance and Polymorphism

Welcome to part 5 of CS101: Inheritance. We’ve made some good progress covering classes and objects. It’s time to explore one of their most useful features, inheritance. As we covered in the last post, methods are a great way to reuse code. Reusing code is fantastic- instead of building a feature or system from scratch every time you begin, you can Lego-together existing methods and objects into new functionality. There’s no need to reinvent the wheel every time you need to sort a list, pathfind, or do any other task that’s common to multiple parts of your program. But what if two classes need to share a method? Maybe you have a HealthPotion that needs to restore health to any character in your game, whether they’re a Warrior, a Wizard, or a Goblin. Instead of writing a different giveHP() method for each class, we can use inheritance to give them shared behavior. A diagram should help:

inheritance_diagram_1

As shown in this diagram, a Wizard is a Unit. So are Warrior and Goblin. These three classes are now subclasses of Unit. That makes Unit their superclass. You’ll also hear people use the terms child class and parent class. Anything that is present in the superclass can be used in the child class. If you have the same method declaration in the parent class and the child class, the child class overrides the superclass method. That’s what our act()  method does. This means we can start with a generalized class, like our Unit class, and extend it into more specific subclasses. You merely tell an object to act() , and it will perform the appropriate method depending on which subclass it was instantiated from. Radical! Code, as always, will make this clearer:

Phew, that was a lot. Here’s what this outputs:

When we call act() , Java is smart enough to know what class it was originally instantiated from and calls the appropriate method. Not only that, but did you notice the type we declared for each character? They were all declared as Unit. But player isn’t a Unit, it’s a Warrior! That’s the beauty of inheritance- variables declared as a superclass can contain any subclass. Read that again if this is new to you, it’s important. This is called polymorphism. Not to be confused with the magic card, polymorphism is an object’s ability to have more than one is a relationship. As we mentioned up top, our enemy object is a Goblin, but it also is a Unit. That’s huge! It’s simultaneously the entire basis of Object Oriented Programming and a loaded gun to shoot yourself in the foot with repeatedly.

Before we move on, I should also mention the new keywords that showed up in our program, extendsabstract and super. A class that extends another class is a subclass. A method marked as abstract has no implementation. Instead of being followed by brackets, we end it with a semicolon. Abstract methods can only exist in abstract classes. An abstract class cannot be instantiated; it can only be extended. It’s used as a common origin for subclasses that have similar or shared behavior. The keyword super just refers to the superclass. In this case, we use it to call the constructor of the superclass.

We’ve covered most of the “how” of Object Oriented Programming now, which means it’s time to talk about the why. Join me next time when we talk about treating objects like people.

Next post: Object Oriented Programming

Leave a Reply

Your email address will not be published / Required fields are marked *