This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Recently i came across the following piece of code wherein i found an interface with ONLY constants.And that constants were accessed in classes using static imports. The constants were more in number (around 30 to 50).Personally, i don't think it's a good practice. Thats why its called as Constant Interface Antipattern according to Effective Java. I don't find any good reason to go for this kind of coding.
Also, static import should be used ONLY if there are few constants to be imported by many classes in our application.
Can anyone of you please let me know if there are any other good reasons to go for constants only interface??
Java has gotten rid of the entire notion of a textual preprocessor (if you take Java as a "descendent" of C/C++). We can, however, get the best benefits of at least some of the C preprocessor's features in Java: constants and conditional compilation.
One of the inarguably good features of the C preprocessor is the ability to define compile-time constants using a textual name to represent some value. This makes it easier to read and maintain. It is also faster at runtime than using a normal variable.
An arguably abused feature of the C preprocessor is the use of #define along with #ifdef and friends to conditionally compile entire blocks of code. I say it's arguable since people often use this facility to deal with platform-specific issues (and that's both the good point and the bad point).
In C, one could define some constants in a header file via:
#define MY_BDATE 10
and then getting access to those constants by using #include to include them in a code file, and then using them:
fprintf (stderr, "My birthday is on the %d" "th!\n", MY_BDATE);
The equivalent in Java can be done by creating public static final variables in a Java interface:
Then we can access them by using import to make the interface visible to us and then using the constants:
System.out.println ("My birthday is on the " + ConstantStuff.MY_BDATE + "th!");
The C preprocessor can conditionally strip out large areas of text if a given preprocessor constant was or was not defined.
/* Lot's of nasty code to deal with the stupidities of the
* SILLY platform.
/* Code to deal with other, normal platforms. */
Many folks lament that this capability is absent from Java. Remember, one of the reasons that Java is so wonderful is that the language is so much better defined, so system-specific code like that should not even be necessary.
Be that as it may, you can still get that sort of conditionally compiled code from the compiler directly! You just use public static final boolean constants as the condition for a regular if statement. The Java compiler is smart enough to recognize that as a special case and it can completely eliminate the test and the code of the appropriate conditional branch.
So just write the conditional statement as usual.
I don't know about you, but I hate having to write that long-winded interface name before using any of those constants. So, I just have my class that is going to use those constants implement the interface. Then I can just use the name directly, assuming there are no name clashes (in which case you'll have to distinguish them using the full names).
damodar kumar wrote:I don't know about you, but I hate having to write that long-winded interface name before using any of those constants. So, I just have my class that is going to use those constants implement the interface. Then I can just use the name directly, assuming there are no name clashes (in which case you'll have to distinguish them using the full names).
That's why static import was invented (in Java 5). With a static import you can use the constants without the class/interface name, without having to implement the interface, avoiding the worst of the anti-pattern.
So it's recommended that you use an abstract class to hold the constants instead. static import works in both cases, but this prevents you from using the poorer practice of implementing the interface.
Not an abstract class - a final class with only one private constructor. That's what java.sql.Types is. In essence:
An abstract class can still be extended, and a constants class should not be extended.