CMPS 144 Spring 2024
Prog. Assg. #2: CalendarDateF (F for "format")
Due: 11:59pm, Tuesday, February 27

There are several commonly used formats by which to describe calendar dates. Among them are ones that we will call MDY, Y_MON_D, and Month_Day_Year. Here are examples:

MDYY_MON_DMonth_Day_Year
"10/04/1989" "1989-OCT-04" "October 4, 1989"
"3/27/2023" "2023-MAR-27" "March 27, 2023"
"7/14/1878" "1878-JUL-14" "July 14, 1878"

The toString() method of the Java class that was the subject of the previous assignment, CalendarDate, produces strings in the MDY format.

It would be nice to have objects representing calendar dates whose toString() methods are capable of producing descriptions of themselves in a variety of formats, including MDY and others. That is the goal of the CalendarDateF class, which has been left for you to complete.

Of course, we want instances of this new class to have all the capabilities of instances of the CalendarDate class, too, but without duplicating the code in the latter. For this reason, CalendarDateF is to be a child class of CalendarDate.

The ability to produce variously-formatted calendar date strings is best left to Java classes that are designed specifically for that purpose (as opposed to embedding such capabilities directly in the CalendarDateF class).

For this assignment, you are to implement three such classes, each of which supports one of the formats mentioned above, as suggested by its name.

Each of these classes is to have a single public method with this specification/heading:

/* Returns a string --in the format supported by this class--
** describing the given calendar date.
*/
public String image(CalendarDate date)

Of course, private methods (and variables, for that matter) are allowed within such a class.

Suppose that calDate refers to an instance of the CalendarDateF class. How is it supposed to "know" which calendar date format its toString() method should produce?

One idea would be for CalendarDateF to have a (non-standard) toString() method that receives a parameter indicating which format it is to produce. The specification/heading of such a method could look like this:

/* Returns a string --in the format specified by the argument--
** describing the given calendar date.
*/
public String toString(CalDateFormat format)

The data type of the formal parameter, CalDateFormat, is shown in red so as to draw your attention to it. To what is it referring? The intent is that the formal parameter format should be capable of receiving instances of any of the classes CalDateFormat_MDY, CalDateFormat_Y_MON_D, CalDateFormat_Month_Day_Year, or any other (as yet non-existent, even) class that supports (via its image() method, as described earlier) some calendar date format.

Given your prior exposure to the concepts of inheritance and, in particular, abstract classes, what you may have realized is that, to make this work, CalDateFormat should be an abstract class (with the abstract method image()) having each of CalDateFormat_MDY, CalDateFormat_Y_MON_D, and CalDateFormat_Month_Day_Year as one of its children.

Yes, that would work. A slightly better approach is to make CalDateFormat into an interface rather than an abstract class. An interface is like an extreme version of an abstract class in that all of its methods are necessarily abstract. Also, a class implements an interface rather than extends it. (This subtle distinction is reflected in the syntax of the class's heading.)

In addition to having the non-standard version of a toString() method, as described above, it would be nice for the CalendarDateF class to have a standard, zero-argument, toString() method. But what kind of a string should that method produce?
Answer: An object of the CalendarDateF class should have an instance variable, of type CalDateFormat, whose image() method it uses to produce that string! And how would that instance variable get a value?
Answer: In either of two ways. One is via a parameter passed to the constructor. The other is via the method setFormat(). See the relevant source code for clarification.

Links to relevant Java artifacts


Submitting your work

You should submit four Java source code files to the appropriate Brightspace dropbox, namely those whose links above are followed by the statement "To be completed by student".

Remember to include in the header comments your name, a list of names of people who aided you, and a description of any defects you are aware of.