Design Theory

[Kris Reid]

This is a theory kind of question as it has no real effect on the code, which I believe makes a valid post for meaningless drivel. Just looking for the more correct implementation.

It is quite common to have a class or interface holding a bunch of constant values

    
public interface SomeConstants
{
public static final String NAME = "My String";
public static final int NUMBER = 5;
}

Do you think it is better design to make this an interface or a class or even an abstract class?

And if you decide to make it an interface should the using class implement the interface or use these constants via a "static" SomeConstants.NAME; If a class should it be extended or even instantiated?


I've been arguing with myself for sometime on this and can think of valid points for every argument.
Why can't there be just one right answer, damn it!

[ankur rathi]

Originally posted by Kris Reid:
This is a theory kind of question as it has no real effect on the code, which I believe makes a valid post for meaningless drivel. Just looking for the more correct implementation.

It is quite common to have a class or interface holding a bunch of constant values

    
public interface SomeConstants
{
public static final String NAME = "My String";
public static final int NUMBER = 5;
}

Do you think it is better design to make this an interface or a class or even an abstract class?

And if you decide to make it an interface should the using class implement the interface or use these constants via a "static" SomeConstants.NAME; If a class should it be extended or even instantiated?


I've been arguing with myself for sometime on this and can think of valid points for every argument.
Why can't there be just one right answer, damn it!

Can you put some advantage of making it a class or abstract class???

Any mover???

[Ankur Sharma]

Originally posted by rathi ji:


Can you put some advantage of making it a class or abstract class???

Any mover???

This is discussed many times and at a very good frequency in JAVA FOrums.

and this discussion concerns with JAVA not related to MD..

Moving to Java in General (beginner)

[Kris Reid]

I can argue that it should be a class

1. It is not a contract which is what an interface is for
2. It should not be declared as implement and should be accessed in a static way - making it a class

I just put an abstract class to throw in another point of argument.
I guess this is could be done so the class is not instantiated



Java Beginner - ohh the offence! Highly intellectual and important discussion.
Nothing to do with me being bored and not wanting to code the damn class/interface

[Devesh H Rao]

Originally posted by Kris Reid:
I can argue that it should be a class


I just put an abstract class to throw in another point of argument.
I guess this is could be done so the class is not instantiated

But what if the abstract class is extended and the constants redefined [Sorry did not notice the "final" in the first post] ....?
Why not make it final class and give it a private default constructor...


Or write a warning in the class that the class is not to be instantiated and if it is instantiated, then the class is coded to send out a hidden email detailing the person instantiating the class and which could lead to legal proceedings against the person

Is this MD stuff now ?

[ September 27, 2006: Message edited by: Devesh H Rao ]
[ September 27, 2006: Message edited by: Devesh H Rao ]

[ankur rathi]

Originally posted by Kris Reid:
I can argue that it should be a class

1. It is not a contract which is what an interface is for
2. It should not be declared as implement and should be accessed in a static way - making it a class

I said advantages, though I agree with your first point, second point is bit confusing to me...

[Jim Yingst]

[Kris]: This is a theory kind of question as it has no real effect on the code, which I believe makes a valid post for meaningless drivel.

No, this is about Java programming, it's not an MD topic. I'm moving it to Java in General - Intermediate.

[Jesper de Jong]

And if you decide to make it an interface should the using class implement the interface or use these constants via a "static" SomeConstants.NAME; If a class should it be extended or even instantiated?

NO it should NOT implement the interface just because it needs the constants. Doing that is called the constant interface anti-pattern.

Why is the constant interface anti-pattern bad? Because you are introducing constants into the public API of your class just because you need those constants for the implementation of the class.

In a good design, the public API of a class should not depend on the implementation details of the class. Implementation details should be hidden behind the scenes and not leak into the public API.
[ September 27, 2006: Message edited by: Jesper Young ]

[Tony Morris]

Originally posted by Kris Reid:
[QB]

    
public interface SomeConstants
{
public static final String NAME = "My String";
public static final int NUMBER = 5;
}

// pointless since int is an axiomatic data type.
interface Number {
    int getNumber();
}
 
// potentially pointless (since it is not clear if String
// is an axiomatic data type ( we know that a sequence of
// homogenous type is, therefore is List<Character> which
// is exactly equivalent in formal spec. ?))
interface Name {
    String getName();
}

This kind of code is usually driven by the fear of the "magic numbers" anti-anti-pattern. If so, the premise of the question is flawed.