At the end of this lesson, you will know…
- Why you might use inheritance.
- How to use inheritance and base classes
There is a lot of repetition in the class properties
Right now, we have seven classes in the Engine project: HealingPotion, Item, Location, Monster, Player, Quest, and Weapon.
You may have noticed that some of the classes have very similar properties. Some of the classes also represent the same type of thing. For instance:
- HealingPotion, Item, and Weapon all have the properties ID, Name, and NamePlural. They all also represent items that a player may collect during a game.
- Player and Monster share CurrentHitPoints and MaximumHitPoints. They are both “living creatures” in the game.
When you have classes that represent the same type of thing, and have similar properties (or functions, as we’ll see later) that mean the same thing, you may want to use inheritance – another aspect of object-oriented programming.
We’re going to make the Item class the base class for HealingPotion and Weapon, since all of those classes have the properties that are in the Item class.
Then, we’re going to create a new LivingCreature base class, to hold the shared CurrentHitPoints and MaximumHitPoints properties of the Monster and Player classes.
Here is how we do that.
Step 1: Start Visual Studio Express 2013 for Desktop, and open the solution.
Step 2: Double-click on the HealingPotion class, in the Engine project. Change line 9 to this:
public class HealingPotion : Item
Adding the colon and Item class name after the HealingPotion class name is how we show that HealingPotion has a base class of Item. So, all the public properties and methods from the Item class now automatically show up in the HealingPotion class, even after we delete the lines for the ID, Name, and NamePlural properties.
HealingPotion is now a “child class”, or “derived class”, from the Item class. Those are the common terms you’ll hear other programmers use, for classes that inherit from another class.
Now, we can remove the ID, Name, and NamePlural properties from HealingPotion, since they are in the base class.
One of the most popular benefits of a base class is that you don’t need to duplicate properties and methods in all of its child classes. Child classes have access to variables/properties/methods/etc. that are in the base class – as long as their scope is not “private”. Anything that is private is only visible inside the base class.
So, the ID, Name, and NamePlural properties are now “in” the HealingPotion class, because they are in its base class, and not private.
Step 3: Do the same thing that you just did to the HealingPotion class to the Weapon class – add the Item base class and delete the lines with the three properties that are already in the Item class.
Step 4: We don’t already have a class with the properties we have in common with the Monster and Player classes, so create a new class, named LivingCreature, with the integer properties for CurrentHitPoints and MaximumHitPoints. Be sure to make this class public. A base class needs to be at least as visible (with regards to its scope) as its child classes.
Step 5: Change the Monster and Player classes so they have LivingCreature as a base class (add the colon and LivingCreature to the lines that start with “public class”), and remove the CurrentHitPoints and MaximumHitPoints properties from those two classes – since they’ll now use the properties from the base class.
Step 6: In the UI project, view the code of the SuperAdventure form (right-click on SuperAdventure.cs). Notice that there is no red line under the Player CurrentHitPoints and MaximumHitPoints properties on lines 25, 26, and 31 – even though you just deleted those properties from the Player class. That’s because the class inherited those properties from its base class – LivingCreature.
Step 7: Start the program, so you can see that the CurrentHitPoints value is still correctly displayed on the screen.
Now you know how, and why, you would create base classes for the classes in your program. This is especially helpful when you write larger applications, and you want to make sure that classes that are similar all act in a similar manner.
Base classes also let you share functions (Lesson 09), so you don’t have to duplicate the same code in several places – and worry about accidentally mistyping something in one of them.
There are some more advanced conditions to what is visible from the base class, in the “child” classes. But we won’t get into those in this guide.
Source code for this lesson
Previous lesson: Lesson 06.1 – Creating the remaining classes
All lessons: Learn C# by Building a Simple RPG Index