Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How do you usually define constants with a package?

Status
Not open for further replies.

coospaa

Programmer
May 1, 2003
33
0
0
SG
The only solution I can find is to define an "Constants Interface" like this:

interface Constants
{
static final public int SUCCESS=1;
static final public int FIAL=0;
... ...
}
Then, every class in the package using these constants has to implement this
interface.

An abstract final class defining these constants is an alternative, but then I
have to site the class name when using the constants, like this:
if( dosth()==Constant.SUCCESS)
{... ...}

Im wondering if there is any other better solutions to define package constant
s? You know, Im some kind of new comer to java but am involved in a java proj
ect now.

Thank you very much.
 

Code:
public class Constants {
    static final public int SUCCESS=1; 
    static final public int FIAL=0;
}
 
I don't see any problems defining constants in an interface. It's perfectly sound and legal.

~za~
You can't bring back a dead thread!
 
I bet for the constant class thingie. It's clearer for me.

Dian
 
Thanks guys:) I think the class solution is better.
 
like I said, there is no right/wrong answer. However, remember, Java allows only a single inheritance to take place. If I read it correctly, you want to define all constants in one class. Hence, given a class A, if you want to use the constants, you say,

public class A extends Constants{}

If later on down the road, you have to do a design change and let say you want to extend a abstract method, you cannot extend anymore classes. But if you use a constant interface, you can implement it as many times you want since many interfaces can be implemented for a single class.







~za~
You can't bring back a dead thread!
 
you don't have to mention the interface name every time you want to use the constants,

if you do this (then you don't have to mention the word
Constants every time

public class MyClass implements mypackage.Constants{

//hence, you don't have to use Constants.SUCCESS
//to use the constants
if( dosth()==SUCCESS)
{... ...}

}

or

import mypackage.Constants;

public class MyClass implements Constants;

don't you love Java?



~za~
You can't bring back a dead thread!
 
As he mentioned, implement the interface. Also remember, you can implement multiple interfaces with one class/interface/abstract class. So, placing the constants in an interface would be a more viable solution. Also, you may want to ask yourself if these constants should really be defined inside a class you are already using somewhere, if they have a relationship to it... Something to consider in design.
 
This was a very good an interesting discussion and I enjoyed reading it. I'd like to give a star to everyone that took part in this discussion but I think that this would be a little bit exaggerated.

However, I am very interested in topics like this one. Just getting some tips about general thoughts and philosophies on designing java programs.

Are there more of these topics hidden in this forum or are there websites with good content about this topic (links please)?


Cheers

frag

patrick.metz@epost.de
 
I totally agree maxpower1, there's no rigth/wrong answers. It will always depend on the kind of application you're working on.

Anyway, I still want to give my vote to the constants class option.

It's true that you have to write the class name everytime you use a constant, but with today's complete-code IDEs functionalities, it's not a really hard task to do.

Using the Class.Constant notation, the code is esaier to read and more clear. Imagine, for example, the you're writing a Java code that uses SQL and HTTP. The SUCCESS code for each language will be a differente value.

So if you have constant classes you will be able to easily distinguish between MySQLClass.SUCCESS and MyHttpClass.SUCCESS

This is specially important when you have large projects with a lot of classes involved.

Another good thing is that you can use the constants in any part of the code without changing the declaration of the class. If you use interfaces, everytime you use a new constant, you need to check if the class is implementing that interface. When the project grows, that can be difficult to read and understand.

An import statement is always easier than an implements one.

Of course, that's just my opinion, you can agree ... or be wrong :p

Cheers

Dian
 
Arghh, I forgot the most important part.

Max, when I define constant in a class, I don't extend the class when I want to use them. I just make an static reference to a final variable.

Cheers.

Dian.
 
Type safe? What is stopping them from NOT using the satic varibles and passing an unexpected number. One of the big reasons that booleans aren't ints in Java is that you can't pass an int in, when you need a truth value... So, logically, wouldn't you want to use the java enumeration pattern (depending on what the varible is) so that someone can't pass
Code:
9
instead of
Code:
Constants.SUCCESS
...

I typically put the static constants in the class that they have to do with. One thing that I typically make static in server classes is the port number - if I don't want it to ever change. I will sometimes purposefully and willfully violate DRY (don't repeat yourself) in the case of the client... I don't want to have to package my server with the client.
 
Interestingly, during a recent interview I was asked to discuss the disadvantages of using an interface to define constants.
 
Humm, so the interviews are becoming soft. When I was doing interviews, I once was asked how to implement multiple inheritance in Java.



 
Diancecht,
thanks for the class option. I'll put it in the backburner. I read Designing better Applets and Applications by Peter Coad. He pretty much likes design with interfaces.

>Humm, so the interviews are becoming soft. When I was doing >interviews, I once was asked how to implement multiple >inheritance in Java.

Are you sure it was not a trick question ;) Or that guy got it all wrong?

tricksy! wicked! false! - gollum

~za~
You can't bring back a dead thread!
 
And who is Peter Coad? :p

Anyway, I will reconsider the interface option, but I think I'm too used to the class thingie.

And about the interview, it was not a tricky question. The exact question was: "You know Java doesn't allow multiple inheritance so ... how would you implement it if needed in a Java program?"

Cheers

Dian
 
peter coad wrote this book:-

Java Design: Building Better Apps and Applets (2nd Edition)

an excellent java design book. In use it in conjuction with Martin Fowler's "Refactoring" book.


~za~
You can't bring back a dead thread!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top