PI: Laboratory 2: Interfaces, Classes, and Objects

• Home
• Mechanics
  
  • Initial Handout
  • Syllabus
  • Learning Objectives
  • People
• Course Notes
• Assignments
• Links
• Wiki

Overview

Before you start this lab, make sure you have read the chapters in the book on interfaces (chapter 4), classes (chapter 7) and object oriented design (chapter 8). You will be writing a lot of code in this lab, and you will need to be thoroughly prepared for it.  You must have pre-written the code for the pre-lab; writing additional code beyond that will give you more of a chance to experiment in lab.

As usual, you should read the general information handout for the collaboration policy. For this assignment, you may discuss the project in as much detail as you like with your classmates, but you should do the writeup on your own. You may also get comments from other students on all portions of your writeup before turning it in, if you wish. Please include the names of anyone with whom you collaborate, in any way, on this assignment, and indicte the nature of the collaboration. [Failure to include this information is a violation of the collaboration policy.]

You will be printing out and turning in the code you write for this lab. This code must be your own. We do encourage you, however, to ask your classmates for help debugging. Helping someone else debug their code is a great way to improve your own programming skills.

This assignment emphasizes the following topics

• Understanding classes and instances (objects)
• Using and implementing interfaces

This assignment is due at 5pm on Wednesday, February 12th, 2003.

Contents

• Pre-Lab
• Finger Exercises
Do the lab preparation exercises, marked with a Q. There are no additional finger exercises this week.
• What to Expect in Lab
• Lab Preparation
• Interfaces we've already implemented
• World
• Interfaces you must implement
• Ball
• Animate
• Pre-lab questions
• Laboratory
• What to bring to lab
• Setting up BallWorld
• Writing your first class: Dud
• Man, that was boring.
• Zoooooooom!
• Other fancy stuff
• Gravy

• Post-Lab, AKA What To Turn In

Pre-Lab

A. Finger Exercises

B. What to expect

All balls, no matter what their class, share some characteristics.  A ball must have horizontal and vertical coordinates. It must have a size. It might even be able to respond to the mouse or keyboard.  In fact, every ball will have to respond, but some will respond by doing nothing. We'll capture these concepts of "ballness" in an interface.

The distinction between interfaces, classes, and objects can be confusing, so we'll recap it here and elsewhere in this lab:

• An interface describes some kind of useful commonality among a set of things. For example, the Ball interface will specify methods you might want to invoke on a ball: getting its coordinates and radius, or telling it that the user clicked on or typed at it.  An interface specifies only the method signatures, not their implementations.
• A class is like a recipe or factory. It describes a way to create objects with a specific behavior. The class specifies the names of the fields, and defines exactly how each method is to be executed. Two different classes might implement the same Ball interface but the different classes might specify different behaviors for their methods. For example, one class might ignore mouse clicks while the other changes the position of the ball to the location of the mouse click.  Remember that a class must implement every method promised by the interface.
• An instance is made from a class. The instance object is stamped out of computer memory according to the instructions in the class factory. The instance contains the actual data specifying the particular state of the individual ball: the fields declared in the class definition become actual dials and labels in each instance object. Two instances of the same class will have the same methods and general behavior, but might have different field values.

As long as the classes that you write implement the Ball interface, the graphics code that we've already written will know how to ask your object what its position and radius are.

Interface  interface Ball double getX();  double getY();  ...

Class  class MyBall implements Ball double x;  double y;  double getX() {    ...  }  double getY() {    ...  }  ...

Object  x   y   double getX() {    ...  }  double getY() {    ...  }  ...

C. Lab Preparation

This week, you gotta do it yourself.

You'll be creating an entire class from scratch. The class is a template for all of the information you might want about a ball: its horizontal and vertical position, its radius, some interaction with the user, and the behavior that the ball displays.

The cool part about this lab is that you'll be able to write different classes for different behaviors: one class might describe the rules for a ball that bounces off the sides of the window, one class might describe the rules for a ball that just stays in one place and gets bigger and smaller, and one class might describe the rules for a ball that gets bigger and then splits into two balls.

So how does this work? The code you write is pretty simple. All you really need are methods that describe where your ball is, how big it is, and what to do when the user clicks or types at your ball. Other classes that we've already written will take care of displaying your ball on the screen.

Interfaces that we've already implemented

The answer is that we will define an interface (actually, two of them), which specify the methods you must write. The two interfaces are Ball and Animate. Together, these two interfaces specify seven methods that you must write for your class. We'll get to the actual methods below.   Remember, interfaces are contracts that specify what behavior will be provided.  An interface doesn't provide the behavior, though.

It may be that your class needs to talk to our class to get some information, like the size of the window. How do we allow you access to the important parts of our class without exposing all the gorey graphics and other methods? We do that with yet another interface, World. This time, we've implemented the World interface; you can use our methods, and you don't have to write any of these yourself.

Here is the World interface:

public interface World
{
   public double getMinX();
   public double getMinY();
   public double getMaxX();
   public double getMaxY();

   public Ball getClosestBall(Ball fromBall);
   public void addBall(Ball aNewBall);
   public void removeBall(Ball toBeRemoved);
}

   Ball myNeighbor= theWorld.getClosestBall(this)

The addBall method is useful if you have created a brand new ball from scratch, and you want to tell the World about it so that it'll appear on the screen. The removeBall method tells the World to erase the ball you passed as a parameter and forget that it ever existed.

Interfaces you  must implement

public interface Ball
{
   public double getX();
   public double getY();
   public double getRadius();

   public void setWorld(World theWorld);

   public void userClicked(double atX, double atY);
   public void userTyped(char key);
}


public interface Animate
{
   public void act();
}

When the user clicks the mouse on the screen representation of your ball, our graphics class finds your ball object, and calls the userClicked method that your ball provides.  It tells the userClicked method the x and y coordinates of the click. Similarly when the user clicks on your ball and then types a key, our class calls your userTyped method with the character that was typed. You need to implement methods that tell your ball what to do in these circumstances.  In the beginning, you might want to do absolutely nothing.  You will still have to provide a method, but the method doesn't have to do anything.  Of course, if you want to make your ball interactive (later), the methods are there.

The remaining Ball method is setWorld. Our behind-the-scenes class calls your setWorld method with an object that implements the World interface. If you want to use it later to figure out the bounds of the screen, for example, then you better save it away in a field.

One thing that the Ball interface doesn't cover is how to make your ball have an independent behavior. We use the Animate interface for that. For as long as your ball is on the screen, the act method will be called over and over again. The act method is very much like the code that you wrote last week for the etch-a-sketch lab.   The act method is the heart of your ball's behavior:  it is the rule that your ball will use to figure out what to do.

Remember that one class can implement more than one interface, so you should only have to define one class for any given ball type.

Pre-lab Questions

Q: Your ball classes will implement both the Ball and Animate interfaces. Suppose you want to write a ball class called "Bouncer". How would you write the first line of the class?

Q: What methods must your class have?

Q: Write an entire class called Dud that implements Ball and Animate. The ball represented by a Dud object should just sit at (0, 0) with a radius of 5 and should do absolutely nothing.

Q: What would happen if you created two Dud instances?

Q: The Dud class you just wrote didn't really need any fields (if you used fields anyway, then you were probably thinking ahead). Suppose that we want to keep the x, y, and radius values for the class in fields, so that later we can change their values. What would you have to add to or change in the Dud class to do this?

Q: Read ahead in this lab to the place where you define the act method in the Bouncer class (under Zooooooom!). Write down the fields you'll need for Bouncer, and also write down the body of the act method, and the constructor.

Q: Check out the following code. Assume that theWorld is a field that has already been set up appropriately, and that the code you're looking at is part of a method in a class that implements Ball. Can you figure out what might go wrong?   (Hint:  look carefully at the documentation for the World interface, above.)  How would you fix it?

   Ball closest = theWorld.getClosestBall(this);
   double xdist = closest.getX() - this.getX();

Laboratory

What to bring to lab

Setting up BallWorld

Writing your first class: Dud

• Click the toolbar icon directly beneath the File menu (tooltip "New Text File").
• Type in the code that you brought in for your Dud class.

   package ballworld;

Once you have saved the file, you can add it to your project. Make sure your Dud.java window is at the front, and then select "Add Dud.java to Project" from the Project menu.

What methods must your Dud class implement?  Make them as simple as possible.

Compile your code and make sure there are no compiler errors. If you get a bug, and you can't seem to figure out why, please ask a classmate or one of us for help. Debugging is an art that takes a lot of practice and experience. Helping other people debug their code is a great way to get that experience.

Before you run the code, you must tell the program the name of the class you wrote. Bring up the Target Settings Panels by hitting Alt-F7 (or by clicking the rightmost button left of "ballworld Debug"). Select "Runtime Settings". Adjust the "Program Arguments" line to include Dud. As you create more classes, you'll add the class names to the Program Arguments list, each separated by a space.

Click OK, and run your code. You should see a green field with a button underneath that reads "Dud". Push the "Dud" button. Voila! a black dot in the center of the green field.

Man, that was boring.

Change the userTyped method so that when the user types a 'd' character, your method tells the world to remove this ball. Did you remember to keep the World object from setWorld in a field so you could use it later? If your field was named world, you can write this.world.removeBall(this); The removeBall method will remove your dot from the screen and stop calling your act method.

Compile and run your new Dud code. If that worked, we can make Dud even more interactive by changing the x and y locations when the userClicked method is called. Make sure you have x and y fields, and set them according to the parameters in userClicked. Compile and run, and now you've got a dud you can drag around with the mouse. Try it!

Zoooooooom!

Once again, click the "New Text File" toolbar button. Copy and paste the entire Dud class from the Dud.java window to this new window. Rename this class Bouncer by changing class Dud to class Bouncer. Save the file as Bouncer.java and then choose "Add Bouncer.java to Project" from the Project menu.

Note: be very careful when copying large chunks of code from one class to another, or even from one method to another. There are all kinds of things that can go wrong when a field from one class gets copied and then changed in another class. The only reason we're having you copy the text now is that it's a pain in the @#%$! to retype the entire thing over again. Later in the course, you'll learn all about how to take advantage of code you've already written so that you don't have to do these massive, dangerous copy and pastes.

The body of the act method is almost exactly like the code you wrote for the etch-a-sketch lab last week. For this class file, you'll use the constant-velocity code you wrote last week. Remember that you'll need fields for x and y, and for xVel and yVel, the x and y velocities.

Let's initialize the xVel and yVel fields to 0.1 and 0.2, respectively. There are two ways to do this. One is simply by defining the values on the same line that you declare the names and types:
double xVel= 0.1;

A nicer way to do this is in the class's constructor. The constructor for the Bouncer class would look like this:

public Bouncer()
{
   // constructor stuff goes here
   // ...
}

Remember that the constructor doesn't have a return type, just a name, and that name must match the name of the class exactly. Inside (where we have a comment), you can put any initialization code you want. This code will be executed just after the object is created out of raw stuff, but before anything else happens. In particular, be careful, because there is no World that you know yet! So you can't use world.getMaxX(), for example, to do anything. Can you figure out what would happen if you tried?

Since you've written a new class, you need to tell the program about it by adding Bouncer to the Program Arguments list in the Target Settings Panels (ALT-F7).

Compile and run your code. Now the balls drift off the top right side of the window. Note that your Duds are still duds. Change your act method in the Bouncer class so that the ball bounces off the sides, rather than drifting off the window completely.

You might be concerned at this point whether you can use your world field in the act method. If you are concerned, that's great! If you aren't concerned, you should probably try to figure out why you should be concerned. Once you've done that, put your concerns to rest, because we've written the World object in such a way that we can guarantee that your setWorld method will be called before your act method is called.

Compile and run your new bouncing code. Hit the Bouncer button a bunch of times. Yeeeeha.

Other fancy stuff

Change the act method so that in addition to drifting, the radius slowly gets bigger (say, 0.03 per tick). Have the radius start at 2. When it reaches 5, make the ball explode by removing it from the World.

Add Exploder to the Program Arguments list, and compile and run your code to make sure it works.

Let's do some fireworks. Just before the Exploder removes itself from the world, we're going to make it add two brand new Exploders. Remember that to create a new object from a class, you use new:

Exploder exp1= new Exploder();
Exploder exp2= new Exploder();

world.addBall(exp1);
world.addBall(exp2);

We can actually write a second constructor for this class:

public Exploder(double startX, double startY) {
   // initialization stuff
   // ...
}

Exploder exp1= new Exploder(this.getX(), this.getY());

This is the end of the target exercise. Anything you do beyond here is gravy.

Gravy

How about falling balls (balls that accelerate down, and bounce when they hit the edges)?

How about falling balls that shrink in size and disappear when they get a radius smaller than 0.5?

How about the last generation of Exploders turning into these disappearing fallers instead of more Exploders?

Have fun!

Post-Lab, AKA What To Turn In

• on the front page, how much out-of-class time (approximately) you've spent on reading, on preparation of the homework, in lab, and on other non-class-time course-related activities (and what). These times should include work from last Wednesday 5pm to this Wednesday at 5pm
• your pre-lab assignment, including the written and finger exercises.
• a brief description of your expectations before coming to lab. (This may be a version of your notes for check-in.)
• a discussion of how you spent your time in lab.
• Printouts of all the classes you created in this lab  These should include documentation explaining what the classes are and how they work.  You may add this documentation after the lab, either on-line or on paper.  This documentation is a part of your writeup.
• your observations concerning
• what actually happened.
• how this compares with what you expected prior to lab.
• any interesting behaviors you may have developed.
• a brief description of the check-off interaction, who checked out your laboratory work, and answers to any specific issues s/he may have asked you to address.
• whether the pace of the class is:
  • Frustratingly fast
  • Fast but fun -- a wild ride!
  • Just about right
  • Slow and steady
  • Painfully slow
  • Java Rules!
  Please give a supporting sentence or two.
• the names and roles of any collaborators in any parts of the project.

also note the following:

• How long did this lab take you?
• Did you work with other students? If so, how helpful was it?
• Did you have problems writing code for this lab?
• Did you have problems running/using this lab?