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.

Now that we have this design, are there additional benefits? If the set of constants evolves to become more widely applicable than its parent class it becomes, in essence, an abstraction. It is independent of the original class, which makes things easier on you. Having already separated the two, you are free to widely implement the decoupled constants' interface. An example of this can be found in the SwingConstants interface included in SwingSet.

Parameter Constant pattern

You may be uncomfortable with an interface like CalendarConstants, where the abstraction of the constants truly depends on a single parent class. There is a solution that keeps the interface but uses nested classes to re-encapsulate the constants in the parent class. Let's call this the Parameter Constant pattern and name the interface Parameters. Returning to our Calendar example, this solution encapsulates the constant interface using a top-level nested interface:

  public abstract class Calendar implements Calendar.Parameters {
    public interface Parameters {
      // 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
    }
    // constructors, methods, and fields follow
  }

At first glance, this nesting may seem strange or non-intuitive, but once you see the idea embodied in the code, it makes sense. Other classes can implement Calendar.Parameters or refer to constants directly such as Calendar.SUNDAY, just as before. This nesting solution has the advantage of placing the interface definition properly within its containing class, the advantage of proper containment. Namespace is not polluted with an unnecessarily top-level interface like CalendarConstants. A good candidate for the Parameter Constant pattern is the ScrollPaneConstants interface and its parent class JScrollPane; both are included in JFC's Swing.

Prototype Constant pattern

If you define class prototypes that are constant in the class itself, you can use a similar approach, which we will call the Prototype Constant pattern. Java uses prototypes with java.awt.Color and java.util.Locale. If you could redesign Java's Color class to use the Prototype Constant pattern, you might do the following:

  public Color implements Color.Prototypes {
    public interface Prototypes {
      // Sorry but JavaSoft did not follow uppercase naming convention.
      Color white = new Color(255, 255, 255);
      Color lightGray = new Color(192, 192, 192);
      // and so on
    }
    // constructors, methods, and fields follow
  }

The final concern is whether our approach can accommodate type safety. The constants in Prototype Constant pattern are, by nature, type safe. We can make our Parameter Constant pattern type safe as well while preserving the interface approach. We build upon our pattern with the insights provided by Philip Bishop in Java Tip 27: " Type safe constants in C++ and Java" in JavaWorld. The following is a simple example that does just that, enforcing type safety for the weekday constants of Calendar by introducing an inner class within our Parameters inner interface:

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq