Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design Theory

 
Kris Reid
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1249
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 687
Hibernate jQuery Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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
Java Cowboy
Saloon Keeper
Posts: 15207
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic