To illustrate putting together an object oriented (OO) class hierarchy design, let’s take a look at a simple maze game. We’ll be creating an OO design, but we’re not going to select a programming language at this stage. We’ll see how we can analyse the problem from an OO perspective, and produce a workable OO design solution that can be translated into implementation code.
Our simple game involves a two dimensional maze and two moving objects. The moving objects are the player’s character and a monster that chases the player around while they try to solve the maze. For our OO design, the key here is that, although these two objects have clear differences, initially we’re only interested in what they have in common.
During the game the player’s character and the monster both have to have their screen position stored, and this is best held as a two dimensional coordinate x and y. The point class is a very common class for storing coordinates, and one we’ll use in our design. We also want to know whether or not the characters are alive in the game. To cover these similarities, we can create a class that covers both the game characters, as follows.
We’re using Unified Modelling Language (UML) notation in our class modelling. UML is commonly used in object oriented design, and ArgoUML is a free Java tool you can use to produce your own UML diagrams.
Notice that gameCharacter has not been derived from the class point, but has included a data member currentLocation which is of type point. Now we’ll get on to inheritance as we start to think about the differences between the game characters.
Remember that a class doesn’t just have data members, but also methods, and the methods for the game objects concerning movement are very different. The player character is going to be moved in response to player commands, while the monster will need an Artificial Intelligence (AI) game function to make it move in pursuit of the player.
There are also different data requirements. For the player, we want to keep a score, and what level of maze they’ve reached. For the monster, we at least want to have a speed variable, so that we can have it move faster or slower.
Note that there are a number of functions that have been ommitted from the class designs, particularly how to get and set the values of the various class data members, assuming they are private class members, but the basics are there. With thought, this class tree can be extended in all sorts of ways. Various game characters might be derived from the gameCharacter class, or from the monster class, whichever makes most sense. You can see that using inheritance each derived class provides greater and greater specialisation, but that the base class provides a foundation of reusable code to build upon.
Next we’ll take a look at times when a class may be designed that has more than one bass class, known as multiple inheritance.