Designing the Calculator

I started with a simple application in mind – a “calculator” style device that, given two calendar dates, computes the difference between the two, and reports the difference in years, months, days, hours, minutes and seconds. I sketched out a basic pencil and paper diagram of the initial concept:

  Date Calculator Concept

Figure 1 – Initial Conceptual Layout

I decided on some basic design strategies:

Fortunately the Java SE run-time library (rt.jar) provides a GregorianCalendar class, which extends the abstract Calendar class.  GregorianCalendar contains everything I need to manage my calendar data and calculate date/time differences.  By instantiating this class I could manage the user-specified Start Date/Time and Finish Date/Time as two instances of a Calendar object, startCalendar and finishCalendar, respectively.  I can perform all date/time difference calculations are on these two objects essentially though the methods provided by GregorianCalendarVoila, a major amount of work accomplished without having to write more than a few lines of code! (I provide some basic technical information on the Gregorian Calendar at the end of this discussion.)

To conform to separation of functionality using the Model-View-Controller paradigm, it seemed logical to place the Model, View, and Controller code in three separate packages:

  • datecalculator – (the View) to lay out the Calculator graphics, to manage the INPUT operations such as populating the ChoiceBox data, handling button events, and menu selections, and to display results in the OUTPUT fields.
  • dcops – (the Controller) to manage startCalendar and finishCalendar objects, and to perform all calculations using these two objects to get the results.
  • dcstore – (the Model) to manage all persistent data (persistent data is data maintained in a local file or in some non-local location). 

At some point in my initial calculator design I thought it would be a useful feature to be able to automatically populate the date fields, rather than select the same values over and over.  I was using my birth date/time as a working example in the graphical layout, so that decision was a no-brainer (a classic example of “Requirements Creep”, by the way!).  It seemed natural to provide the capability for a user to save and retrieve startCalendar and finishCalendar dates, so I added the concept of an Event (in retrospect maybe a poor terminology choice, but it got locked in early and I never went back and changed the notation).  This naturally led to the need for a user to be able to save and load an Event into the Calculator from a persistent data store.

Using basic Object Oriented principles, it was obvious that I extend GregorianCalendar and create a subclass (naturally enough called EventCalendar) that allows me to maintain Event name and date information, and to utilize the features of GregorianCalendar on my startCalendar and finishCalendar objects. 

At this point I have a working concept and the basic Calculator design in place. So let’s discuss how this whole project gets off the ground.