In his book Effective Java, Joshua Bloch recommends against using Interfaces to hold constants,
The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class’s exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the con-stants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.
His reasoning makes sense to me and it seems to be the prevailing logic whenever the question is brought up but it overlooks storing constants in interfaces and then NOT implementing them.
For instance,
public interface SomeInterface {
public static final String FOO = "example";
}
public class SomeOtherClass {
//notice that this class does not implement anything
public void foo() {
thisIsJustAnExample("Designed to be short", SomeInteface.FOO);
}
}
I work with someone who uses this method all the time. I tend to use class with private constructors to hold my constants, but I’ve started using interfaces in this manner to keep our code a consistent style. Are there any reasons to not use interfaces in the way I’ve outlined above?
Essentially it’s a short hand that prevents you from having to make a class private, since an interface can not be initialized.
I don’t think a class with a private constructor is any better than using an interface.
What the quote says is that using
implements ConstantInterfaceis not best pratice because this interface becomes part of the API.However, you can use static import or qualified names like
SomeInteface.FOOof the values from the interface instead to avoid this issue.