• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Interface with ONLY CONSTANTS

 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello ranchers,

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??

Thanks in advance.
 
Ranch Hand
Posts: 77
Android MyEclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
#define SILLY_PLATFORM]





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.


#if defined(SILLY_PLATFORM)
/* Lot's of nasty code to deal with the stupidities of the
* SILLY platform.
*/
#else
/* Code to deal with other, normal platforms. */
#endif



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).
 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic