The primary goal of this lab is to get practice with basic methods. The logic is very simple in this lab; the point is to become familiar with the syntax of methods and how to document them.
Clone the repository for this lab from the shared class directory:
If you try hg status, you should see nothing, because the working copy and the repository match. If you try hg log, you should see the (short) history of revisions that I made to the repository before you cloned it.
You are the programmer on an interstellar space ship, traveling at light speed.1 Your captain wants to know how far the ship is from our home planet; all you know is how many days you have been been traveling. You are to write a program that asks the user for a number of travel days and displays the distance from the home planet in kilometers.
The speed of light is 2.997925 × 108 meters per second. To take a number of days and compute a number of kilometers using a meters per second rate takes several conversions. We will compute each step in a separate method, using the methods written so far.
Open your source file in Emacs.
Note that it has a main method, and also some method stubs that are commented out. Before you do anything else, fill in the heading comment appropriately. Save your file, and make sure that it still compiles cleanly. To commit your changes to the repository, first check the status with
You should see that just the one .java file is modified. Then do the actual commit with
Note that you do put the message inside quotes.
We’re now ready to begin the actual work. The first piece involves improving the method getDays(). Right now, it prompts for user input, and it hopes that the input provided can be interpreted as an integer. You need to use exception handling so that (a) what it does matches the comment describing it, and (b) it properly handles bad user input.
If you look at the comment, you’ll see that the method should first attempt to get a number of days from the first command-line argument. It should prompt and take input only if that does not succeed, whether because there is no argument or because the argument can’t be interpreted. It should also prompt and try again if the input from the keyboard can’t be interpreted.
Note that you need to put something in main() to see the results while you are testing.
Once you have that working, be sure you commit it to your repository.
You are now going to fill in a sequence of very simple routines that do the conversions a little bit at a time.
First implement the conversion from days to hours. Find the method stub that has the signature
Uncomment that heading, then fill in the body so it works.
After you have written it, you must do two things: document and test. To document, remember the rules for documenting methods. Write a block comment (start with two stars, and with stars all along the left side) containing:
These methods can count as ”trivial,” so you can skip the second part (the description of the algorithm).
So the comment for daysToHours() would look something like:
Test your method by adding code to the main method so that it calls just this method with the input and prints the result. Try a few examples, and make sure it is working. When you are satisfied, commit it to your repository.
Repeat the process in part 5 for hoursToMinutes and minutesToSeconds. Document them properly and test them individually so you know they are right. In order to test, you’ll need to fill in something different inside main().
Then do the same for daysToSeconds, but instead of calculating the conversion directly, have this method call the other conversion methods to get its result. Document and test. Now you know that entire sequence of methods is right.
You can commit at any point that you feel that the program is consistent. If you haven’t committed since completing daysToSeconds, do so now.
Now go ahead and fill in the code for secondsToMeters, calculating distance by time times velocity. You can write big number literals using ”e” (for ”exponent”) to mean ”times 10 to the...” That is, you might make a variable like this:
Or, better yet, make it a constant (by adding final and naming it appropriately).
Document and test. Then repeat the process for one more conversion method, metersToKilometers.
Finally, you can use calls to daysToSeconds, secondsToMeters, and metersToKilometers to write daysToKilometers. Since you’ve tested all the components, you should have nothing to worry about for the correctness of this method.
To wrap up, make sure everything is documented well (including the block at the beginning of the program and including all local variable declarations). Also make sure the main method has been cleared out of testing code, and works now according to the specification.
This would be a good time to commit, again.
This is an American vessel, and your captain doesn’t know what a ”kilometer” is. Write and use an extra conversion method, from kilometers to miles, so that the more familiar unit of measure is used. Make sure that your main method prints the distance now in both kilometers and miles, appropriately labelled.
Don’t forget to commit.
One of the reasons for documenting our methods in exactly the form specified is that it makes it possible for additional tools to produce neatly formatted documentation. You can create the documentation files for your class by running the command
If you use ls now, you’ll see that javadoc has produced a bunch of new files. To see your documentation, you need to open the file index.html in a web browser. For example, you can open it in firefox by running the command
If you have written all of your comments correctly, you should see a nice page that describes all of the methods, including the descriptions of parameters and results. If you notice something that should be fixed, go fix it in the .java file and re-run javadoc. (And don’t forget to commit when you are really done.)
Remove your .class file(s). Then create a script file as before (compile and run). Run the program using 1 day, 5 days, 16 days, and 80 days. Also make sure that your tests show that it can take the number of days from the command line, that it handles a non-numeric command-line argument, and that it can handle bad user input.
After you have run the program, include
before you end the script.
Use handin to turn in your source file and the script file as lab5. Do not turn in a printed copy.
You can find instructions for cloning (copying) the repository to your account at the end of the last lab or on the Mercurial tips page.
Keep in mind that the script file is not in your repository; so if you want it you will need to copy it separately.
1This is clearly a fictional starship, of the sort appearing in most popular science-fiction stories. Neither special relativity nor general relativity applies. Unlike some of the best-known fictional starships, however, this one is not subject to temporal anomalies.