CPSC 170 Lab 5
Events, Interfaces and Polymorphism

As usual, create a lab5 subdirectory for today's lab, open this document in FireFox, and start emacs.

Thinking about Events

Throughout this class, we have been working with event-based programming. The general idea is that things can happen during the execution of the program that we wish to respond to. To capture these events , we establish listeners . A listener is simply a block of code that is executed when a certain event occurs. For example, to respond to a button being pushed, we define an ActionListener. Since we want to respond to different events in different ways, we would like to extend the capabilities of the ActionListener to suit our needs.

However! ActionListeners only do one thing - respond to an "actionPerformed". Moreover, since we are always going to specify what to do in case there was an "actionPerformed", the actionListener is actually abstract!

So, we have an abstract class, where all methods are abstract - this is a good candidate for an interface! Therefore, when we define a class to respond to events, we don't extend ActionListener, we ___________________________________ ActionListener.


We typically think of events as being something that the user has done, i.e. clicking on a button, but that is not always the case. We might also be interested in generating events at regular intervals. For example, we might want a program that checks for new e-mail every 15 minutes. To acheive this, we use a Timer object to generate events for us. A timer object has an interval, measured in milliseconds, and a listener that defines the code to be executed after the interval of time has elapsed. (see page 470-474 or JavaDoc for more details)

Download the file drawBars.tgz . Uncompress it using the command

tar xzf drawBars.tgz
This should containt three files: bars.java, BarsPanel.java and drawBars.java Compile drawBars.java and run the file. Observe what it does (be patient, there is a timer in there!)

You should have noticed that the bars changed color, one by one -- if you didn't know better, you would expect that there was a for loop or a while loop controlling the color change. Examine the code to find out what is really going on. Before you move on, you should make sure that you understand:


Often when we sort, especially small lists, the computer is done before we know it (and that's a good thing). However, since we are just getting started with sorting, it is useful to break down the sorting process to allow us to get a better sense of what is happening.

We are going to sort the bars (according to height), using a selection sort (refer to the code on p 500). Instead of doing the entire sort at once, we are going to use the timer to delay processing and see incremental steps. To achieve this you should:

Print your work to turn in.


Consider the game of Monopoly. The game consists of a sequential set of 40 squares containing 28 properties, 6 Action squares (3 "Chance", 3 "Community Chest"), 2 Tax squares, "GO", "Jail", "Free Parking", and "Go To Jail.". The game is played by moving through the set of squares. Every time a player lands of a square, they take a different action, depending on the type of a square. For example, if you land on a "Tax Square", you must pay the bank a certain amount of money, but if you land on an "Action Square" you must draw a card from the appropriate pile and follow the instructions on the card.

Note that this is a perfect example of polymorphism. Take a deep breath and relax, you are not implementing Monopoly during this lab. However you are going to use polymorphism to describe the gameplay. To accomplish this you should:

Print your work to turn in.