Where to define application-wide constants

[Ahmed Moustafa]

Where should application-wide contants be defined e.g. in a class or an
interface?

Thanks in advance!

 

[Joe]

Where should application-wide contants be defined e.g. in a class or an
interface?

Thanks in advance!

They should be public static final members of an abstract class.

 

[Ahmed Moustafa]

They should be public static final members of an abstract class.

Why abstract class?

 

[Roedy Green]

Where should application-wide contants be defined e.g. in a class or an
interface?

Java 1.5 has a new answer to that old question.

 

[Ahmed Moustafa]

Java 1.5 has a new answer to that old question.

enum?

 

[Joseph Millar]

Where should application-wide contants be defined e.g. in a class or an
interface?

I tend to put them in an interface. But it really depends on the
values and their relationship to the rest of the code. It sometimes
makes sense to define public static final items in the classes which
use them, but stuff that is truly global to an app kinda cries out
for an interface of their own. YMMV

--Joe

 

[Roedy Green]

enum?

no, a way of exposing constants so they don't need the class name
qualification.

 

[Chris Smith]

no, a way of exposing constants so they don't need the class name
qualification.

You mean "import static"? I agree that, all things considered, it's far
better to use "import static" than implement an interface full of
constants. Nevertheless, I wonder about the desire to hide context in
the first place. The net effect is to make it more difficult to assume
that a method or variable is directly related to the current class.

That said, I'd much rather have "import static" than a solution that
forces the use of unqualified constant or method names.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ahmed Moustafa]

Where should application-wide contants be defined e.g. in a class or an
interface?

Thanks in advance!

How about the Singleton pattern? Does it make any sense to implement a
singleton to hold global constants/variables?

 

[Ahmed Moustafa]

no. You have all the fuss of creating the singleton and the extra
overhead of finding the singleton. The constants are no longer static
finals, so you can't use them in case statements.

Just make them static finals in either an interface or class.

My constants include matrices that I load from a text files, I hold
these matrices in a class that extends HashMap and the keys are the
names of the files.

The class is going to be Singleton because I need only one instance per JVM.

Should I load all the text files in the constructor, which happens only
once? Or, should I load each file upon demand and if it has been already
loaded, I don't load it again?

 

[Roedy Green]

My constants include matrices that I load from a text files, I hold
these matrices in a class that extends HashMap and the keys are the
names of the files.

The class is going to be Singleton because I need only one instance per JVM.

You can still implement this as purely static variables. They will be
loaded the first time you use the class. There is no need to go to
the hassle of creating a singleton object.

The hassle may be worthwhile when you plan to subclass the singleton
object, or if you suspect the object won't always be a singleton.