"Constant Interface Antipattern" ?

Hey, can somebody please elaborate to me what "Constant Interface Antipattern" mean. It wasn't much clear to me reading about it in java documentation.
Thanks

An Anti-Pattern (generally speaking) is a design approach that has several drawbacks.

As for the Constant Interface Anti-Pattern, check here http://en.wikipedia.org/wiki/Constant_interface

Hi Deepak,

the Constant Interface Antipattern is about defining constants in interfaces and then let the classes, in which these constants are used, implement these interfaces.
It is a kind of workaround for some people because in Java a Class can't inherit from multiple classes (but it can implement multiplei nterfaces)

If you do a search for this you should find plenty of threads on the net, e.g.:

Constants Interface Antipattern

The problem is that you add stuff to the interface of this class which doesn't belong there.

Some say you should completely avoid to use interfaces to define constants, because you provoke people to use them in the Antipattern way.
You can find an alternative aproach in the link above.

Hope this made it a little clearer to you...

John

Little clearer now.....thanks

Deepak,

You can create an interface like this:

The reason why this is a bad idea is that the interface, instead of specifying a contract for behavior (methods), just passes some not too meaningful constants around. You're much better off creating a class.

John.

The real problem about implementing John's interface is that all classes implementing it now expose public A_CONSTANT_INT and A_CONSTANT_STRING fields for the whole world to see, and once these classes have been used by other classes, those fields can't be changed for fear of "breaking" those unsuspecting "other classes".

John de Michele wrote:You're much better off creating a class.

Yes. Or these days you might consider creating an Enum for a group of related constants.

Thanks guys.
Lesson learnt:

1) Don't create interfaces just for using constants globally.
2) Use a ~~private~~ public class instead, class with a private constructor and static constants, and then statically import them.

I hope I got this right.

Thanks again.This is great forum for beginners like me.

Why not use a public class (with a private constructor) to encapsulate your public static final variables?

That was what I actually meant. . .

hi all,
there is a nice way to use constants defined in a class to use it in another class.(applicable for java1.5 onwards).
here it goes:

public class Constants {
//Constants for other classes
static final String HOST_NAME = "host_name";
.
.
}

import static Constants.*;
class UseMyConstants {
String hostname;

init(){
hostname = HOST_NAME;
}

}

all d best...

See this: Java 5 New Language Features - Enums

One of the reasons for adding enums to Java is to avoid the constant interface anti-pattern.

In prior releases, the standard way to represent an enumerated type was the int Enum pattern:
// int Enum Pattern - has severe problems! public static final int SEASON_WINTER = 0; public static final int SEASON_SPRING = 1; public static final int SEASON_SUMMER = 2; public static final int SEASON_FALL = 3;
This pattern has many problems, such as:

Not typesafe - Since a season is just an int you can pass in any other int value where a season is required, or add two seasons together (which makes no sense).
No namespace - You must prefix constants of an int enum with a string (in this case SEASON_) to avoid collisions with other int enum types.
Brittleness - Because int enums are compile-time constants, they are compiled into clients that use them. If a new constant is added between two existing constants or the order is changed, clients must be recompiled. If they are not, they will still run, but their behavior will be undefined.
Printed values are uninformative - Because they are just ints, if you print one out all you get is a number, which tells you nothing about what it represents, or even what type it is.