Implementing interface with no methods

[william kane]

What is the benifit of defining an interface with only constants but no methods and implementing the same interface in other classes?
I have seen this style of design in many open source applications.
Why cant the contants in the interface be just referenced where ever required instead of implementing the interface?
Thanks in advance
William

[Ernest Friedman-Hill]

Well, the reason people do it is to save typing; that's it. If you implement the interface, you get to type the names of the constants as unqualified names.

This is called the "constant interface pattern." Folks who write about such things have decided this is bad. Joshua Bloch's "Effective Java" makes a detailed case against it.

I personally remain unconvinced. I've been told this means I've never worked on a sufficiently large project to see the problems emerge, but I've worked on million-line codebases that use this pattern and still haven't seen any problems due to it.

In any case, Java 1.5's new "static imports" feature lets you import constants explicitly into a translation unit without re-exporting them as if you had implemented a constant interface.

[Jeroen Wenting]

In practice it's not bad. According to OO theory it's abhorrent because interfaces define contracts between classes and constants are not contracts but rather implementation details.
So it's more a theoretical than a practical antipattern.

[David O'Meara]

It all depends on your background and point of view. If you've ever had to support code written by graduates who though this was a good thing you too would stear clear.

My specific case is two-fold, created by people over using constant interfaces and having a poor understanding of inheritence, and what we ended up with was a complicated interface/object heirarchy mess where it was significant effort to find the definition of one of these constants.

You could argue that experienced programmers wouldn't create this mess, but if it isn't really required why go down that road, and why promote it?

[Sreenivasa Majji]

What about you using an interface with constants (no methods) and using it in other classes (only import, no extending).

I used to create a class with private constructor and all the constants and use this in other clases.

Which one is better?

[Ilja Preuss]

Originally posted by Jeroen Wenting:
In practice it's not bad. According to OO theory it's abhorrent because interfaces define contracts between classes and constants are not contracts but rather implementation details.
So it's more a theoretical than a practical antipattern.

I think it becomes an antipattern when it's overused or used in the wrong context. For example I wouldn't do that for classes which are part of a published interface, simply it would expose clients of that class to its implementation details.

When used with care, I don't see any problems, though. On the other hand, with Tiger the need to do that really vanishes.

[Ilja Preuss]

Originally posted by Sreenivasa Majji:
What about you using an interface with constants (no methods) and using it in other classes (only import, no extending).

I used to create a class with private constructor and all the constants and use this in other clases.

Which one is better?

I don't see any significant difference, but I might be missing something.