use interface or class for declaring constants?

[Rajeshwari Natarajan]

Hi all,
How should we declare and use constants in a project?
Should constants (public static final variables) be declared in a class or in interface?
Many argue that we should not use interface since we are not implementing any behaviour. This is true if my class implements the interface containing constants.
But what if all I do is import the interface and make use of the constant?

public class CONSTANTS {
 public static final String CONST_UID = "scott";
}
public interface ICONSTANTS {
 String CONST_UID = "scott";
}

public class Test
{
//code which uses the constant CONST_UID
}

In the above piece of code, what difference does it make if I use
CONSTANTS.CONST_UID or ICONSTANTS.CONST_UID? Is there any difference in performance?
Which is the correct approach?
[ November 23, 2003: Message edited by: Rajeshwari Natarajan ]

[Stan James]

The interface technique is fairly common, but generally seems like a convenient perversion of OO goodness. Sun seems to agree in that the 1.5 JDK has a new construct just for this kind of thing. Darned if I can remember the name right now! Anyhow, I don't use the interface technique. It seems right to me for a class to own the constants and for those who use them to acknowledge the dependency by referencing the class. Counterpoint?

[Brian R. Wainwright]

This example is fairly rigid, but... as background I've implemented the Data Access Object (DAO) pattern in my app and, in order to improve extensibility, created an interface that outlined what methods need to be defined for a particular DAO. The DAO's now use JDBC to connect to a MySQL database, but because they implement an interface, I can change that data source to say an XML datasource and garauntee to other application layers that the "getUserFromLogin" method is always going to be there because the interface that the DAO's implement require it to be defined. The SQL statements for accessing the DB are defined as constants in the DAO. Had I defined them in the interface, I'd be losing that flexibility of another implementation. This is is a fairly obvious example, but illustrates the point which is, "Think about what you're doing." Using interfaces as a design practice is great for future extensibility and flexibility. Ask yourself, are the constants you define in an interface an implementation specific detail (like SQL statements)? If so, then they don't belong there, put them in the concrete class.

[Lewin Chan]

Depends on the situation.
Generally a class not an interface. However, if I have a class full of private constants (and code), and suddenly the constants need to be exposed to a.n. other package/class, then I almost always use an interface. That is just because I'm lazy, implement an interface, and you inherit all those constants with no code changes.
Lewin

[Ilja Preuss]

Originally posted by Lewin Chan:
Depends on the situation.
Generally a class not an interface. However, if I have a class full of private constants (and code), and suddenly the constants need to be exposed to a.n. other package/class, then I almost always use an interface. That is just because I'm lazy, implement an interface, and you inherit all those constants with no code changes.

Yes, I do that, too. I know that it's frown upon; but till today it didn't bite me. So what?

[Ilja Preuss]

Originally posted by Stan James:
Sun seems to agree in that the 1.5 JDK has a new construct just for this kind of thing. Darned if I can remember the name right now!

Static Imports.
Basically, you can write
static import java.lang.Math.*;
and later simply write
double x = sin(PI);

Anyhow, I don't use the interface technique. It seems right to me for a class to own the constants and for those who use them to acknowledge the dependency by referencing the class. Counterpoint?

I do have a TableMarkupWriter and a TableMarkupReader class. Which one should own the constants?

[Stan James]

Um, TableMarkup? Seriously, if it was easy, they wouldn't pay us so much.

[Ilja Preuss]

Originally posted by Stan James:
Um, TableMarkup?

Yep. Do you think it should have some behaviour? Or would it be ok to just make it an interface and let both Reader and Writer inherit ("implement") it? Serious question.

Seriously, if it was easy, they wouldn't pay us so much.

Yes. And if it was easy, I wouldn't ask questions here...

[Rufus BugleWeed]

Does anybody have a copy of Joshua Bloch's Effective Java? Item seventeen, Use interfaces only to define types deals with this issue. I do not own a copy or I would reread this item. IIRC, he discourages the practice of defining constants in interfaces.

[Allan Halme]

Originally posted by Ilja Preuss:
I do have a TableMarkupWriter and a TableMarkupReader class. Which one should own the constants?

My convention would be a TableMarkupConstants class.

[Ilja Preuss]

Originally posted by Allan Halme:

My convention would be a TableMarkupConstants class.

How do you reference the constants in the Writer and Reader?

[Allan Halme]

Originally posted by Ilja Preuss:
How do you reference the constants in the Writer and Reader?

  
package com.company.demo;
/** Note may be neat to have this package-level visible. */
class TableMarkupConstants
{
    public static final String FOO = "foo";
}

  
package com.company.demo;
public class TableMarkupWriter
{
    public void aMethod()
    {
        String foo = TableMarkupConstants.FOO;
    }
}

[Ilja Preuss]

I feared you might answer that way...
Seriously, I think that the endless repetition of the class name just adds too much clutter to the code. Implementing an interface removes that clutter and didn't have any bad side effect till now, as far as I know.
Of course, using static imports would be more "pure". I will certainly do so when it's available.