Laboratory Exercise

Object Oriented Programming in Java

Supplemental Material for Baldwin and Scragg, Algorithms and Data Structures: The Science of Computing; Charles River Media, 2004


Purpose

This lab reinforces understanding of basic object oriented programming concepts (objects, classes and subclasses, methods) and their expression in Java. It also provides practice using non-object aspects of Java (loops, conditionals, etc.)

Prerequisites

Understanding of Chapter 2 of Algorithms and Data Structures: The Science of Computing.

Understanding of basic Java syntax, as described in appendix A to Algorithms and Data Structures: The Science of Computing.

Background

This lab exercises many of the object oriented programming concepts discussed in Chapter 2 of Algorithms and Data Structures: The Science of Computing (for instance, objects, messages, methods, classes and subclasses). The lab does this by asking students to extend the abilities of the robots introduced in Chapter 2, and then use the extended robots to solve a certain problem.

Robots

This lab involves defining a subclass of the Robot class from Chapter 2 of Algorithms and Data Structures: The Science of Computing.

Programs that use the Robot class need to include two Java files: Robot.java and RobotRoom.java. The “Final Details” section of this document explains how to find these files and their documentation.

Any Java source file that refers to the Robot or RobotRoom classes should “import” those classes, via the statement

    import geneseo.cs.sc.*;

at the beginning of the file.

Constructors in Subclasses

A constructor is basically a method that initializes a new object (see Sections 3.4.2 and A.4.4 of Algorithms and Data Structures: The Science of Computing for more on constructors). In Java, constructors have the same name as the class they initialize — for example, the constructors for Robot objects are named Robot, the constructors for instances of a hypothetical ExtendedRobot subclass of Robot would be named ExtendedRobot, and so forth. Note that subclasses don’t inherit constructors from their superclass the way they inherit other methods — for example, even if a constructor for Robot logically does everything necessary to initialize instances of an ExtendedRobot subclass, there is no way to automatically apply this constructor to ExtendedRobot objects.

Even though Java doesn’t do it automatically, one often wants to initialize instances of a subclass by just calling a superclass’s constructor. This will probably be the case for the subclass of Robot defined in this lab. To do this, define constructors for the subclass that do nothing but call the corresponding superclass constructor. Within a constructor, the word super can be used to call a superclass constructor. For example, to allow instances of an ExtendedRobot subclass of Robot to be initialized with their position, heading, and room (just like the four-parameter constructor for Robot does), include the following constructor in ExtendedRobot:

    // Within the ExtendedRobot class...
    public ExtendedRobot( int column, int row, int heading, RobotRoom room ) {
        super( column, row, heading, room );
    }

A statement such as the following implicitly uses this constructor to initialize an extended robot:

    ExtendedRobot r = new ExtendedRobot( 1, 3, Robot.NORTH, myRoom );

Exercise

Do the following…

Part 1

Write a subclass of Robot that handles the following messages. Don’t forget to test the subclass, to make sure that each method works as intended:

void travel( int n )
This message causes a robot to move forward n tiles. The message has a precondition that there are no obstructions within n tiles in front of the robot.
void travel()
This message causes a robot to move as far forward as it can, stopping when it comes to an obstacle. (Note that even though this message has the same name as the above “travel” message, it is distinguishable because it has a different set of parameters — no parameters in the case of this message, versus one integer parameter in the case of the previous “travel”. Many modern programming languages distinguish between messages based on their parameters as well as their names in this manner.)
void face( int direction )
This message causes a robot to face in the direction specified by direction. The message has a precondition that direction is one of the direction constants defined in the Robot class (i.e., Robot.NORTH, Robot.EAST, Robot.SOUTH, Robot.WEST).
boolean isFacing( int direction )
This message returns True if a robot is facing in the direction specified by direction, and False otherwise. The message has a precondition that direction is one of the direction constants defined in the Robot class (i.e., Robot.NORTH, Robot.EAST, Robot.SOUTH, Robot.WEST). This message has a postcondition that the robot is still facing in its original direction (i.e., the message does not cause the robot to change direction).
void switchColors( java.awt.Color c1, java.awt.Color c2)
This message causes a robot to paint the tile underneath itself color c1, if the tile is initially color c2. Conversely, if the tile is initially color c1, then the robot paints it color c2. If the tile initially has neither color c1 nor color c2, the robot does nothing.
void passColor( int n, java.awt.Color c )
This message causes a robot to move forward until it has passed (i.e., moved off of) n tiles of color c. This message has preconditions that there are n color c tiles somewhere in front of the robot, with room to pass the nth without hitting any obstructions. Note that the color c tiles may not be next to each other, and that the robot may or may not start on the first. This message has a postcondition that the nth color c tile is the tile immediately behind the robot.

Part 2

Write a main program that creates two instances of the subclass from Part 1, positioned arbitrarily in a room, and then makes those two robots move until they are next to each other. More precisely, the code that moves the robots until they are next to each other should have preconditions

This code should establish the postcondition

(Notice that what these pre- and postconditions do not say is just as important as what they do say: for example, the preconditions do not allow assuming that the robots start in specific places, or with specific headings. The postconditions do not require the robots to be on particular tiles, or have particular headings.)

Some, but not necessarily all, of the messages handled by the new subclass will probably be helpful in making the robots stand next to each other.

Final Details

The Robot Class

Students can download both Robot.java and RobotRoom.java from the Web.

Documentation on both classes is also available on the Web. The main documentation page is an index to documentation for all the Java classes written for use with Algorithms and Data Structures: The Science of Computing. To see the documentation for a specific class, click on that class’s name in the left-hand panel of the page.

Submitting Your Work

This lab is due on Monday, January 31. Turn in a printout of your Robot subclass and main program. The printout should show both the code for making two robots stand next to each other, and any code you wrote to test your subclass.

Finally, notice that algorithms such as those in Part 1 do not have to be written as methods of a subclass of Robot. They could simply be written as separate subprograms, like the first versions of the drawSquare and drawLine algorithms in section 2.3 of Algorithms and Data Structures: The Science of Computing. Write a couple of sentences comparing these approaches to coding algorithms. For example, you could comment on what advantages and disadvantages you see to each approach, you could talk about why you think I asked for one approach rather than the other, or you could talk about any other area of comparison that occurs to you. (Note that you do not have to talk about the things I suggest, they are simply suggestions to start your thinking — if you have another comparison to make, by all means make it. In general, I will be more impressed with one thoughtful comparison than by a list of shallow ones.)


Portions copyright © 2004. Charles River Media. All rights reserved.

Revised Jan. 23, 2005