Java Tip 50: On the Parameter Constants pattern

Combine nested interfaces and class constants for flexible design and easy access to constants

By Jon Steelman, JavaWorld.com, 04/01/98

Classes often contain public static final fields (that is, "constants") used as parameters when invoking their methods and constructors. Java's own Calendar class provides a good example of constants for days of the week and months of the year. Take a look at some abbreviated source code for Calendar:

  public abstract class Calendar {
    public static final int SUNDAY = 1;
    public static final int MONDAY = 2;
    // and so on
    public static final int JANUARY = 0;
    public static final int FEBRUARY = 1;
    // and so on
    // constructors, methods, and fields follow
  }

Rather than embedding the constant definitions directly in the class, Java Tip 5:" Java constants," by John D. Mitchell, reminds us that it's possible to group together constants in an interface and implement the interface in a class in order to use unqualified references to the interface's constants. For example, client classes that work with Calendar may have many method invocations of Calendar with many references to the constants. For a given Calendar object, you can change the month with the following statement:

  aCalendar.set( Calendar.MONTH, Calendar.FEBRUARY );

However, if the client class implements an interface that defines the Calendar constants, you could directly refer to the constants without fully qualifying them as follows:

  aCalendar.set( MONTH, FEBRUARY );

This is how the changed design looks:

  public interface CalendarConstants {
    // fields in interface are implicitly public, static, and final
    int SUNDAY = 1;
    int MONDAY = 2;
    // and so on
    int JANUARY = 0;
    int FEBRUARY = 1;
    // and so on
  }
  public abstract class Calendar implements CalendarConstants {
    // constructors, methods, and fields follow
  }

This change to Calendar does not impact preexisting code that refers to the constants -- either code in Calendar itself or code in client classes that refer to the constants fully qualified, which is obviously helpful if you decide to transition a class to this approach. Client classes of Calendar are free to implement the interface and refer to the constants directly. You can also combine client classes that implement the interface with other client classes that fully qualify each constant. An example of such mixed usage can be found in the ScrollPaneConstants interface included in the Swing packages of the Java Foundation Classes (JFC). This coding shortcut comes in handy when you have a client class that works extensively with the constants from a class like Calendar -- though a few references to constants might not justify implementing the interface in a client class.