wood burning stoves 2.0*
The moose likes Java in General and the fly likes Design Theory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Design Theory" Watch "Design Theory" New topic
Author

Design Theory

Kris Reid
Ranch Hand

Joined: Jan 05, 2005
Posts: 247
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



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
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
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



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???
Shaan Shar
Ranch Hand

Joined: Dec 27, 2005
Posts: 1249

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)


The Best way to predict your future is to create it - Every great individual common man
Kris Reid
Ranch Hand

Joined: Jan 05, 2005
Posts: 247
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
Ranch Hand

Joined: Feb 09, 2002
Posts: 687

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
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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.


"I'm not back." - Bill Harding, Twister
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14269
    
  21

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 ]

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Kris Reid:
[QB]





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.


Tony Morris
Java Q&A (FAQ, Trivia)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Design Theory