Defining constants in an interface: the good pattern

In a previous post I analyzed a bit the constant interface pattern and I got to the conclusion that there is nothing horrible defining constants in an interface so long as long there is no any class that implements the interface.

The problem is that you may implement the interface. The reason to do that may be sheer ignorance or just simple mistake.

The first and easiest solution is to use @interface keyword instead of interface. This will define an annotation interface that can be implemented by a class but it requires the definition of the method

@Override
public Class<? extends Annotation> annotationType() {
    return null;
}

If this does not stop somebody implementing the interface “accidentally” then nothing is.

Also since this is not a usual practice to implement such an interface Eclipse will not offer the interface after the implements keyword for completion.

My personal taste however is not compatible with this approach. This is technically possible, but I consider this rather to be an entry in some weird obfuscated code contest than production code.

The solution I prefer over the previous one is a nested structure. The outer element is a class that has an interface and a class inside. The interface is private thus you can not implement it outside even if you are ignorant. This interface defines the constants. Since the interface is private the constants can not be accessed from outside directly, but we overcome this obstacle. Along with the interface there is a final and public member class. This class implements the interface (sorry for the purists) and contains a private default constructor. But this is all it does. The template code for this looks something like:

public class ConstantClass {
  private interface ConstantInterface {
    int a = 13;
  }
  
  public final class Constants implements ConstantInterface {
      private Constants(){}
  }
}

Since the class Constants is final it can not be extended, and since this is the only class for which ConstantInterface is visible there can be no other classes that implement the interface. This ensures that the constant interface pattern step number 2 (implementing the interface by a class) can not accidentally be done and thus the interface can not leak into the definition of any class except the very one Constants class.

The use of the constants is the same as they were defined directly in the utility class.

If you compare this pattern to the pattern that is using a utility class to define constants you see that this pattern does not require you to use the keywords public static final in front of each constant. This is a bit more error prone as you can not forget the keywords. On the other hand this pattern is more complex.

There is also an advantage of this pattern that shines in the unlikely case when there are many constants you want to structure and group into different groups. You can have many private member interfaces each defining one set of the constants and then many member classes that can implement one or more of the interfaces. This can give you a very structured way to define your constants. If you have many. Which, to be honest, is not likely to happen. If you only have a few constants then simply go on with the good old utility class solution. Using a pattern should make your code simpler and not more complex.