

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Material Type: Lab; Professor: Carver; Class: Programming w/Data Structures; Subject: Computer Science; University: Southern Illinois University Carbondale; Term: Fall 2009;
Typology: Lab Reports
1 / 2
This page cannot be seen from the preview
Don't miss anything!


Your first lab will be a straightforward lab focusing on reviewing Java. You will write classes for a (very) simplistic calendar application, along with a method for testing your classes. The calendar application will involve three classes: Date, Event, and Calendar. You will also write a class TestCalendar that contains a (main) test method.
Specification for the Date class:
Specification for the Event class:
Specification for the Calendar class:
The TestCalendar class must have a main method that performs reasonable testing of your other three classes. You are free to add additional helper methods if you want.
You must define each class in a separate Java source file (.java file), with the name of the class (e.g., Date.java, etc.). You are free to use any development platform that you wish, but if you use an IDE, you must be able to locate the .java sources files. We will do code submissions via email (unfortunately). You should email just your Java source files (.java files) to [email protected], using the subject “CS220 lab1 submission.” Files should be sent as attachments only, so their formatting is not destroyed. It is also allowed for you to send a .zip (or .tar) file archive containing all of the needed files (not .rar files!). You will receive an email acknowledgement that the files were received and readable. Improperly submitted files will be rejected. While late submissions will generally not be accepted, some allowance for email will be made. However, if you want to claim that your email submission failed, be prepared to display the returned email message or similar. Do not leave extra/unwanted code in your submissions. This particularly means main (testing) methods, as well as printing statements for debugging. You should provide reasonable documenta- tion for each method, but we will not be requiring javaDoc style documentation with this lab. Some aspects of the implementation are not fully specified above. One is access control. The basic rule you should follow is to limit access to fields and methods as much as is possible—i.e., only those classes that definitely need field/method access should be able to get it. This is the basic idea behind encapsulation in OOP. However, since we have not yet looked at packages, I do not want you using them to control access. This effectively leaves you with either public or private access options. Use what is most appropriate. The other major element that is unspecified, is what to do in case of errors. Since we have not yet covered Java’s exception mechanism, you are to use a standard type of approach that is used in languages like C that do not have an exception mechanism. The approach is to: (1) print an informative error message; and (2) then terminate the program with an error return. Error messages should be printed with the println method of the java.io.PrintStream class. The standard stream for printing error messages is known as standard error. To print to this stream, you would use a call like: System.err.println(). You can terminate a running program by calling the exit method in the java.lang.System class. The syntax is: public static void exit(int status). By convention, a status of 0 (zero) means success, while a non-zero status such as 1 (one) means failure. Obviously, if you are exiting due to an error, you want to return a failure exit code such as 1 (one). So such a call would look like: System.exit(1).