Question

I wrote a class named Easter (see below) and a tester class named EasterTester (also below that) to execute it and plug in year values. The goal is implementing Gauss’s algorithm for calc’n the month and day of Easter Sunday for any specified year.

My code works fine, but I am having a bit of confusion with my book I am following. It tells me not to implement the two getter methods at the bottom of my first code link because I “don’t need them.” As my code stands, I definitely need them. Is there something I am missing involving that?

Additionally, it lists the “Easter Class Public Interface” that I am recommended to use as:

calculateEaster(int aYear): String

“The UML method syntax indicates the method takes an integer parameter and returns a string.” I do not understand this comment, and consequently, I don’t understand how to edit my code in order to follow these guidelines.

If anyone can offer any clarity on the dilemma/question I would be greatly appreciative!

Code:
/**
*
* @author b_t
*
*/

class Easter {

/**
 * @param n is the month
 * @param p is the day
 */
private int n;
private int p;

// Comments via Cay Horstmann's "Big Java" 4th ed. on page 169; p.4.19

// Let y be the year (such as 1800 or 2001).

/**
 * 
 * @param y this will hold the year that users enter
 */
Easter(int y) {

    // Divide y by 19 and call the remainder a. Ignore the quotient.
    int a = y % 19;

    // Divide y by 100 to get a quotient b and a remainder c.
    int b = y / 100;
    int c = y % 100;

    // Divide b by 4 to get a quotient d and a remainder e.
    int d = b / 4;
    int e = b % 4;

    // Divide 8 * b + 13 by 25 to get a quotient g. Ignore the remainder.
    int g = (8 * b + 13) / 25;

    // Divide 19 * a + b - d - g + 15 by 30 to get a remainder h. Ignore the quotient.
    int h = (19 * a + b - d - g + 15) % 30;

    // Divide c by 4 to get a quotient j and a remainder k.
    int j = c / 4;
    int k = c % 4;

    // Divide a + 11 * h by 319 to get a quotient m. Ignore the remainder.
    int m = (a + 11 * h) / 319;

    // Divide 2 * e + 2 * j - k - h + m + 32 by 7 to get a remainder r. Ignore the quotient.
    int r = (2 * e + 2 * j - k - h + m + 32) % 7;

    // Divide h - m + r + 90 by 25 to get a quotient n. Ignore the remainder.
    n = (h - m + r + 90) / 25;

    // Divide h - m + r + n + 19 by 32 to get a remainder p.
    p = (h - m + r + n + 19) % 32;

}
/**
 * 
 * @return n returns the month in which a given year's Easter Sunday will take place
 */
public int getEasterSundayMonth() {

    return n;
}
/**
 * 
 * @return p returns the day in which a given year's Easter Sunday will take place
 */
public int getEasterSundayDay() {

    return p;
}

}

AND HERE IS THE TESTER CLASS:

public class EasterTester {

public static void main(String[] args)

   {
      Easter myEaster = new Easter(2002);

      System.out.println("In 2002, Easter Sunday is: " + "month = " + myEaster.getEasterSundayMonth() + " and day = " + myEaster.getEasterSundayDay());

      Easter myEaster2 = new Easter(2012);

      System.out.println("In 2012, Easter Sunday is: " + "month = " + myEaster2.getEasterSundayMonth() + " and day = " + myEaster2.getEasterSundayDay());

   }
}

Answer 1

The book’s use of UML like this:

calculateEaster(int aYear): String

really just means that you’d have a public method like this:

public String calculateEaster(int aYear)

(The parameter name is horrible, by the way. If the book suggested using a prefix of a, an, my or the before names, please ignore it… and potentially get a better book.)

I’d argue that the interface would be much better as (in Java syntax)

public LocalDate calculateEaster(int year)

… using Joda Time‘s LocalDate class. If you don’t want to use that, make it return a java.util.Calendar or potentially a java.util.Date. (Neither of those classes really mean what their name implies, and neither is ideal, but there we go…)

… rather than returning a String as the book is recommending. However, it’s fundamentally a difference in terms of what an instance of the object would mean. In your case, it represents a day in the year (although it doesn’t remember which year, which is odd). The book’s recommendation is that there shouldn’t be any instance state – you’d be building an EasterCalculator rather than representing a single instance of Easter.

As an aside, this code is bad:

/**
 * @param n is the month
 * @param p is the day
 */
 private int n;
 private int p;

Your Javadoc comment is trying to document a single field as if it were a method with two parameters. For valid Javadoc, you’d want:

/** The month of the year */
private int n;

/** The day of the month */
private int p;

However, the fact that the fields need documenting is indicative that they’re badly named. Why don’t you just call them month and day instead?