CS Labs: Lab 4

CS Labs: Lab 4

To accompany Chapter 4 of An Introduction to Object-Oriented Programming with Java by C. Thomas Wu.

Defining Instantiable Classes

There are 10 checkpoints () in this lab. If you need help with any exercise, raise your hand.

Copy the lab materials to your account, using the -r option on the Unix cp command, entering

             cp -r /home/Classes/Cs1/Labs/Lab04 .     
This command creates a new directory in your account called Lab04. Everything you need for the lab exercises today is contained in this new directory.

Change directory to Lab04.

Implementing and Testing Methods

Go into the subdirectory ConvertDistance. You will use the Demo class (in the file Demo.java) to test the MetricConverter class (in the file MetricConverter.java). Examine the implementation of MetricConverter carefully.

The MetricConverter class has several methods, some unfinished. To answer some of these questions, we need to explain how to identify a program stub. A stub is a method which is not finished, but has enough code to be compiled and work with other methods. When one or more programmers are writing code, they frequently use stubs as placeholders until the programmer responsible has finished the work. In a stub, the body of the method usually contains only a comment saying 'this is a stub'. If the method needs to return a value in order to compile successfully, the programmer will add a line to return a dummy value such as 0.

Answer these questions for your next checkpoint:

  1. According to the comments, how many methods (including constructors) are supposed to be defined in this class?
  2. How many of these methods are fully implemented? What are their names?
  3. How many are partially defined as stubs? What are their names?
  4. How many of the methods listed in the comments are not defined at all, not even as stubs? What are their names?
1 Call one of us over when you are ready to answer.

As you have seen from the earlier checkpoint question, the centimetersToInches() method is not yet implemented. Using the inchesToCentimeters() method as a model, implement the centimetersToInches() method for your next checkpoint. Make sure to change the comments as well!

2 Show us your finished code for the centimetersToInches() method.

Examine the Demo class implementation. When you run this program, the main() method creates a MetricConverter object and tests the inchesToCentimeters() and centimetersToInches() methods.

  1. Did your centimetersToInches() method perform as expected? (If not, fix it.)
  2. Do you think the main() method thoroughly tests these two methods?
3 Call us over when you have prepared your answers.

At this time, you should finish the implementation of the feetAndInchesToCentimeters() method. As you write it, follow these guidelines:

4 Show us how you implemented and tested feetAndInchesToCentimeters().

Close the files containing the Demo and MetricConverter classes.

Fun with Objects

Go into the subdirectory PointIn2D. You will notice that there is only one class called OurPoint. We named this class OurPoint so as not to confuse this programmer-defined class with the java.awt.Point class that you used in Lab 2. Notice that there is one constructor for OurPoint. What are coordinates of all new OurPoints?

A second constructor for a OurPoint object would be useful, so that we could set the x- and y- coordinate values at the time we construct an OurPoint object.

  1. Implement a second constructor in the OurPoint class that allows the user to initialize a point with an x- and y- coordinate when it is created. For example, the following code should create aN OurPoint named testPoint that has an x-coordinate with value 2.3, and a y-coordinate with value -7.0.
                 OurPoint testPoint = new OurPoint (2.3, -7);
         
  2. Complete the implementation of the setY() stub.
  3. Complete the implementation of the getY() stub.
When finished, take a look at the area of code at the bottom of your OurPoint class that is currently commented out. A programmer who has implemented an instantiable class often tests it by placing a main() method inside that class. Usually, this is done as a temporary measure, since projects may use many different kinds of objects.

Remove the comments that surround this main() method and compile and run the OurPoint class.

5 Show us how you have completed these methods, and the output from the execution of the main() method.

Visibility of Data Members and Methods

Add the following statement at the end of the main() method of OurPoint class

        System.out.println ("The x coordinate of q is: " + q.xCoord);
and recompile this class. Did it compile? Why or why not?

What if you placed the same System.out.println statement in a main() method that was not contained within the OurPoint class? Would this version compile? Why or why not? You can test out your answer. Open the Demo class in this subdirectory. This has a main() method that declares and constructs an OurPoint object q and that contains the statement above. Does this class compile?

6 Answer the questions listed above, and explain the difference between the two situations.

Local Variables and Instance Variables

Go into the subdirectory GetThePoint and open this version of the OurPoint class. This version has a second constructor already defined that allows you to construct an OurPoint object with initial x- and y-coordinates. Examine the code and predict the output. Compile and run this program. Was the output what you expected?

Modify this program so that the output is consistent with values used to construct the OurPoint object q. You are not allowed to change anything in the main() method.

7 When you are ready, call us over and explain what happened before your modification and what you fixed.

Class Methods

Go into the subdirectory ConvertDistance2 and open MetricConverter.java. Note that in this version, the three conversion methods are all class methods. How can you tell this? Notice that the default constructor prints an error message if you try to use it.

Now open the file Demo.java. This is the same file that you used to test your first version of the MetricConverter class in subdirectory ConvertDistance. Compile and run the Demo program and observe what happens.

Modify Demo.java to use this second version of MetricConverter in which all the methods are class methods. You are not allowed to change anything in the file MetricConverter.java.

8 When you are ready, call us over and explain how you can recognize a class method (as opposed to an instance method) by looking at the code in a class and show us your modifications to Demo.java.

Passing Objects

Go into the subdirectory CarAndDriver and examine the files for the Car, Driver, and ServiceStation classes. The Demo.java file creates instances of each of these classes and simulates a driver (named Nigel) driving a car (a Rolls). The Rolls starts out clean but with an empty tank (see the Car constructor) so we must fill its tank before Nigel can drive it.

Compile and run the Demo program and observe the results. Notice, in particular, that the Rolls becomes dirty after Nigel drives it.

This directory has a file CarWash.java that contains most of the implemention of the CarWash class. Open this file and complete the implementation. In the Demo.java program, make a suitable instance of a CarWash object and finish the program by washing the Rolls and filling it with gas (at the appropriate place at the end of your Demo code indicated by comments).

Compile and run your Demo program and observe your results.

9 When you are ready, call us over and show us your completed code for Demo.java and the output of your program.

After the Lab

Don't forget to exit your editor and browser before you log out.

10 Show us that you have logged out, cleaned up, and pushed in your chairs for this last checkpoint.

End of Lab


Susan Haller and Timothy Fossum, University of Wisconsin-Parkside