I was contemplating for the best way to declare constants in Java and found that there are several ways to do it. The best article I saw regading this topic is
here. It helped me decide clearly as to what I should use plus, one of the comments discussed a very interesting information about inlining constants w/c I will also explain later on this blog.
First, I would like to eradicate suggestions/questions that might come up:
Why not use enums? I am referring here to constants that are not related and may even be of different types so enum is not a good choice.
If these constants are not related, why bother grouping them? This is sometimes necessary because there are constants that belong to the same functionality but are not related to each other. You may also want to group constants shared by different classes, more like global constants. These constants do not belong naturally to a certain class so it needs to be grouped somewhere else.
Why not put constants in the class that they are most related to? Aside from the explanation above, this would also lead to dependencies between classes and the constants will clutter. It's always easier to update just one class or few classes.
So what are the options now?
Interface for ConstantsADV:
- cleaner/shorter code because you can define constants without the public static final keywords since they are implicitly public static final
- a class implementing this can refer to the constants without a qualifying class name
DISADV:
- this is not what interface is designed for. Interface is supposed to specify a contract for its services, not to handle data.
- using constant without a qualifying class name can make code more difficult to understand and maintain
- interfaces promotes constants to the API of the class which means that if MyClass implements MyConstantInterface, you can use MyClass.SAMPLE_CONSTANT instead of MyConstantInterface.SAMPLE_CONSTANT. This breaks inheritance and your Javadoc will be full of repeating constants.
Class for Constants with private constructorADV:
- cannot be instantiated and cannot be subclassed like interfaces
- the use of qualifying name can add to the readability of the code
DISADV:
- long name, constants are referred using static references like MyConstantClass.SAMPLE_CONSTANT
static importADV:
- allow referring to constants without a qualifying class name
DISADV:
- can make code more difficult to understand and maintain
MY CONCLUSION: You may choose one over another depending on what you need or what is more convenient for you, but for me the best approach is to
use class with private constructor. This will avoid all the disadvantages of using an interface. If you still want to use interfaces because of the shorter name reference for constants, you must use static import of a constant class instead. However, this must be taken with precaution. Use it only if you need frequent access of constants from one or very few classes only. Otherwise, readers of your code may get confused as to where a constant comes from.
Now, is there anything else that can do better? Apparently, according to Kevin Riff, there is. When a field is (1)of type primitive or String, (2)declared final, and (3)was initialized upon declaration, it is called "compile-time constant" and it is in-lined in the consumer classes. This means that all reference of this constant is replaced with its actual value at compile time. So if you change the value of a constant, you must recompile not only the containing class but all its consumer classes in order to update the value of the constant.
What is the solution for this? Using a properties file could be considered but if you really need to hard-code your constants in a Java file, you must prevent your constants to be in-line like this,
public class MyLibrary {
public static final String VERSION; // blank final
static {
VERSION = "1.0"; // initialized separately
}
}The code would seem odd so don't forget to add comments explaining what's going on.
Personally, I might not apply this design because it makes the code look odd and somehow ugly. I would rather recompile all affected classes. It happens to almost any class anyway that when you make a change on it, there will be some affected classes that must be recompiled too.
