You are given the TimeOfDay class, each instance of which represents a time of day, precise to a minute. (Note that it differs significantly from the version that was discussed in lecture last week.) Not surprisingly, it has two instance variables of type int, one to store an hour value (necessarily in the range [0..24)) and one to store a minute value (necessarily in the range [0..60)).
TimeofDay is an example of a class (like java.lang.String) whose objects are immutable, meaning that their states cannot be modified. (Recall that an object's state is determined by the values of its instance variables.) Indeed, both of TimeOfDay's instance variables are declared to be final, which means that their values cannot be changed after being set by the constructor. (Even if those variables were not declared to be final, the lack of any mutator methods in the class —together with the fact that the variables were declared to be private— makes it impossible for their values to be modified by a client program.)
The only somewhat interesting public method in TimeOfDay is toString(), which produces (with the help of an instance of the java.text.DecimalFormat class) a string of the form hh:mm, meaning a two-digit hour value, followed by a colon, followed by a two-digit minute value. Examples are 19:47 and 08:02. (Notice the leading zeros.) One might say that strings such as these are in the 24-hour format, in contrast to the 12-hour, or AM/PM, format that includes strings such as 9:25PM and 11:06AM.
Ah, but wouldn't it be nice if the toString() method could produce strings of either the 24-hour format or the 12-hour format, under some kind of control by the client?
That's exactly the goal of the class TimeOfDay12Or24, which is a child class of TimeOfDay. Your task is to complete the development of that child class (and to submit it). What is left undone is its toString() method. It is suggested that toString() make use of the two stubbed private methods at the "bottom" of the class (namely hourToAMorPM() and hour24To12()), but that is an implementational detail left up to you.
The idea is that each instance of TimeOfDay12Or24 will be, at any given moment in time, in one of two modes: 24-hour or 12-hour. An instance variable is used for "remembering" which of the two modes is in force, and two mutator methods allow the client program to change an object's mode.
Enter an hour [0..24) and a minute [0..60): 22 45 Time of day (in 24-hour mode) is 22:45 Time of day (in 12-hour mode) is 10:45PM Enter an hour [0..24) and a minute [0..60): 8 2 Time of day (in 24-hour mode) is 08:02 Time of day (in 12-hour mode) is 8:02AM Enter an hour [0..24) and a minute [0..60): 46 5 Hour parameter outside legal range. Enter an hour [0..24) and a minute [0..60): 14 -9 Minute parameter outside legal range. Enter an hour [0..24) and a minute [0..60): xxx java.util.InputMismatchException Goodbye. |
Now, when the toString() method is invoked upon an instance of TimeOfDay12Or24, that method must produce a string of the correct form, depending upon which of the two modes the object is in. In the case of 24-hour mode, you can make use of the parent class's version of toString(). The 12-hour mode case is more complicated. The two DecimalFormat objects created in the method will help. (See how such an object was used in the parent class's version of toString().)
Note: According to some "experts", the expressions 12:00AM and 12:00PM are ambiguous, as either one reasonably could be considered to correspond midnight or to noon. For our purposes, we will consider 12:00AM to be the 12-hour format equivalent to the 24-hour format 00:00 and 12:00PM to be equivalent to 12:00. End of note.
For testing your work, it is recommended that you use the TimeOfDay12Or24Tester application. A sample dialog between it and a user is shown nearby and to the right. An alternative means for testing would be to use jGrasp's Workbench feature.
Submit your completed TimeOfDay12Or24 class to the appropriate folder.