File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is this a right way? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is this a right way? "Defining an Interface to store constants"" Watch "Is this a right way? "Defining an Interface to store constants"" New topic

Is this a right way? "Defining an Interface to store constants"

Naveen Hegde

Joined: Nov 28, 2006
Posts: 17
I have designed a class hierarchy like following.
Interface AllConstants{
//all constants go here
Class Base implements AllConstants{
//all common methods.
Class Task1 extends Base{
//task 1 logic goes here
Similarly i have many other task agents which are derived from Base.

Here i have defined an interface only to define constants. This gives me more flexibility in the classes which want to use it and using the constants in the derived classes is straight forward.
I have seen this kind of usage of interfaces at many places. But in my project, i have received comments saying that this is not a good practice.

Tell me, is this really not a good practice?

Naveen Hegde, SCJP5.0, SCJD...
Ulf Dittmer

Joined: Mar 22, 2005
Posts: 42965
That's the "constant interface anti-pattern", for which you'll get many hits on Google.

Static imports -which were introduced in Java 5- let you do something similar in a cleaner way.
Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
The authoritative source on this topic is Joshua Bloch's Effective Java Programming Language Guide (amazon US)

Item 17: Use interfaces only to define types (p. 89):

When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. That a class implements an interface should therefore say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose."
The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.
If you want to export constants, there are several resonable choices. If the constants are strongly tied to an existing class or interface, you should add them to the class and interface.
If the constants are best viewed as members of an enumerated type, you should export them with a typesafe enum class (Item 21). Otherwise, you should export the constant with a noninstantiable utility class (Item 3).

See also: Using Static Imports For Constant And Methods
Java Practices: Interface for constants
Java Practices: Use static imports rarely
Java Practices: Class for constants
I agree. Here's the link:
subject: Is this a right way? "Defining an Interface to store constants"
It's not a secret anymore!