Earlier we developed a class inheritance tree for some game characters in a maze game, but we need to design another class, or class hierarchy, for the maze. Since we want the mazes to have different levels of difficulty, each level of maze will require slightly different functions.
We can say that each maze, of any level, will be a grid, with each square of the grid being defined as the size of a single game character move. The grid will be stored in a two dimensional array, in which each grid square is represented with a 0 for no wall, or a 1 for wall. There will be one exit defined in the grid with a -1. The maze itself will be randomly created with a function, as will the start location for both the monster and the player character.
At first glance it appears that our derived complexMaze class has only one function, but it has actually inherited all the member functions and data of the base class maze. In that light, you can see that in fact it’s single member function is actually a repeat of the base class’s function, createMaze(). The new createMaze() function will use a completely different algorithm in order to create a more difficult maze. When a derived class redefines a base class’s function in this way it is called overriding, and it is the basic essence of polymorphism.
Polymorphism can cause headaches if programmers are not aware of the version of the function they are using. In this example, if an object is created of type maze and the function createMaze() is called, it will use the version of createMaze defined in the base maze class. If however the function createMaze() is called by an object of type complexMaze, then the version of the function called is the one defined in the complexMaze class. In a very deep inheritance tree it is at least possible that a function may be overridden many times, and a programmer has to be very careful to know exactly which function is going to be called.
It’s also important to note that this is by no means the only solution to the problem. For instance, parameters passed to the maze function createMaze() could just as easily govern the complexity of the maze created. However, there may be other compelling reasons for developing a derived complex maze class, reasons that the project designer must weigh up when creating the class hierarchy. There will often be several different solutions available, and sometimes it may be worth using inheritance and polymorphism, whilst at other times using conditional programming branches might be better. The ability to make these often crucial decisions well and with confidence, like most things, comes with practice and experience.