You have now reached Chrissie's web pages for

Java Programming

Javopoly - Tutorial 3. Base and Derived Classes (Inheritance).

Our third tutorial will further refine the Square class, and introduce you to a new kind of object relationship - Inheritance.

This is one of the three fundamental concepts of programming in Object Technology. These are -

Encapsulation (which we saw last time in the Board class)
Inheritance (which we shall look at today)
Polymorphism (which we shall explore next Tutorial).

You should now also be familiar with the idea that any OOP application will comprise multiple classes and objects. The individual objects contained in any application will, by default, have relationships with each other (they have to, they're in the same program!) and we have already seen two types of relationship....

Simple Association (e.g. one TestDriver is associated with one Board)
Whole-part, sometimes called Aggregation or Composition (the Board was composed of twelve Squares).

We will now look at the third type, Inheritance, sometimes called a Parent-Child relationship, or Base/Derived classes. This involves using a large, general class - in our case, Square - and bolting extra attributes and methods on to it, to make a new, more specialised class.

Think of a plain cake.... which can have candles on it .... or a snowman .... or a couple of extra tiers to turn it into a Wedding cake!

The UML notation for an inheritance relationship between the Base (i.e. the Cake) and Derived (BirthdayCake, XmasCake, WeddingCake) classes looks like this ....

If we look more closely at Square, we can clearly see that there are two very distinct types - those which can be bought and owned by any of the players, and those which cannot. The ten tradeable squares all have the same three "extra" attributes -

an initial purchase price
an owner (which will initially be nobody, of course this changes when somebody buys it)
a rent payable when anybody else lands on it

Although we now have to define and implement a whole new class for PropertySquare, the work involved is actually very little. Remember we have already done the bulk of the work in Square! All we have to worry about is writing code for the extra, or extended, attributes and methods.

Indeed, this is how you define a derived class in Java -

public class PropertySquare extends Square
{
 // and so on

The extends keyword tells us that this is really a Square with extensions. All the attributes and methods available to us in Square will still hold good for PropertySquare, plus the extra bits. Of course we don't have to stop here! In the next tutorial we go on to extend PropertySquare, and we can continue to refine and add derived classes at more and more detailed levels for as long as we wish.

The further down the heirarchy the class appears, the more specialised it becomes, because it has more and more special attributes and methods added on. It will also become much smaller, however; for example we have twelve Squares, but only ten of these are PropertySquares.

Now you may be wondering how we are going to deal with the problem of the rent payable for the Hydro Electric and Watter Works. Although these still have a rent payable, it is calculated in a slightly different way from the eight others, which all have a fixed rent amount. For the moment I am going to leave their rents payable at zero, and sort it out in the next tutorial, when we look at Polymorphism.

In this incarnation I have also added a dialogue to get a die throw for each player in turn. This should be fairly straightforward for you to pick up. (So far we are only playing three rounds of the game, to test it). There is an error handler built in so that the diethrow has to be between 1 and 6, and the position of the player is incremented each time.

What happens if a player is on Rubislaw - squares[9] - and they then throw a 6?

Remember our board consisted of an array, and if we neglected to trap this error, our player would end up on squares{15] - which does not exist. The index would have gone over the end of the array and the program would crash with a NullPointer error.

In reality, if the player's position goes past squares[11], two things should happen -

the position gets reset to 0 the moment it reaches 12
the money held by that player will increase by £200

In the Player class I have added another special method, IncrementPosition(int diethrow), which moves the marker along by the correct amount and returns the new position. This method takes account of passing Go! by using a simple if statement to check whether the amended position is 12 or over. Our Rubislaw player, having thrown a 6, will now be on Watter Works, having collected £200 on the way.

Try it and see!

The new application is contained in this zip file.

Tutorial 4 will refine PropertySquare to even deeper levels of abstraction, move the players round the board and show how to calculate the rents for the Watter Works and Hydro Board using a Polymorphic method. Or to go back to -

Tutorial 1, click here
Tutorial 2, click here


Comments? c.nyssen@abcol.ac.uk Last Updated - 22/11/03

Best viewed at 800x600 in 16-bit high color with Trebuchet MS installed. If you do not have this font, click here