[Jeanne]:Also, "public class MyClass implements MyInterface" is an anti-pattern for inheriting constants. Well, not quite. It's an anti-pattern if the constants are only inherited for internal use, because those constants become part of the public API. It's not an anti-pattern if the constants are
intended to be part of the public API. The best example I know of in the standard libraries are
WindowConstants and
SwingConstants. You're
supposed to see DISPOSE_IN_CLOSE and such when you look at the public API of a JFrame - you use that constant from outside the class. That's fine. It's when you expose purely
internal details that constant interfaces are an anti-pattern.
I admit, I shudder a bit when I hold up something in Swing as an example of good design.

And in the modern age (JDK 5+), all the examples I can think of for a valid constant interface
pattern would probably be better implemented using enums. But remember these were not available when Swing was designed, and the Typesafe Enumeration pattern was not generally known (if it was known at all). So while I may well have doe other things differently, I believe that the use of constant interfaces in WindowConstants and SwingConstants is perfectly valid.
I suspect this is far from shibaram sahoo's original question. That has already been addressed pretty well - but I would add this: why do you think this sort of functionality should be in an interface, anyway? You could simply create a superclass, perhaps an abstract superclass, to include whatever behaviors you want. Of course you can only extend one class in Java - but if that is your objection, then your question is really: why doesn't Java allow multiple inheritance of implementations? This is another FAQ I think. You could probably find many previous discussions of this issue using the Search of FAQ links provided by the forum. I'll skip that though, since I don't even know if that is really your question.
[ August 29, 2008: Message edited by: Mike Simmons ]