Meaningless Drivel is fun!
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes About constants Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "About constants" Watch "About constants" New topic

About constants

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Do you think it is wise to have all text and other constants in separate file? If they should be, should the file be a class or a interface?
I think separate constant file will make the code more maintainable. Think about having the same program in many languages in the future. How nice it is to change only one file when you want to change the language of the program. Anyhow in Code Conventions they say like this:
The names of variables declared class constants
and of ANSI constants should be all
uppercase with words separated by under-scores
(�_�). (ANSI constants should be
avoided, for ease of debugging.)
static final int MIN_WIDTH = 4;
What do they mean with ANSI constants?
Siddharth Mehrotra
Ranch Hand

Joined: Aug 21, 2001
Posts: 185
hi there,
well i made an interface for all the three areas viz, server, client and database.
and as and when i felt the need of a constant that would be used in more than one file. I added it to the interface.
It indeed is a good practice to have all the constants in one place, and by modifying just one file u can modify the entire flow of application.
I guess that gives you a fair idea.

Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
I wouldn't put constants in one source file which can be a class or interface. I believe constants should belong to the class where it needs to be. Others can always refer to these constants as long as they are defined as "public static final".
For example, I've defined the delimiters for search criteria in the Data class. I refer to these constants when building the search criteria. It belongs to the Data class because the logic to parse them out resides in the Data class.
As always there are so many ways to do design in OO world where sometimes it is difficult to pick the right design if there is one. It is your choice and taste.
Colin Froggatt

Joined: Feb 26, 2002
Posts: 10
Hi Jukka, I place class specific constants in the
class itself or related suprt interface if it had one. The only exception to this was a series of constants to define aspects of the record format that were defined in their own interface.
If you are going to use a seperate class/interface to define constants use an interface as it can then be 'implemented' by a class to get automatic access to all constants if required. If you have a lot of public constants that are used by many different classes then I think it probably is a good idea to define them in seperate interface as this will reduce coupling between classes.
On your point about making the app multi-lingual, Java has a built in mechanism for handling this. I think it is reffered to localization or internationalisation and is based on resource bundles that are defined for each country. It';s quite a big subject but check out the java docs and the java.text package as a starting point.
I think doing this for the project would be well over the top but it would be an interesting exercise after completing the cert.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
While this is probably more complexity than Sun would want to see in a project, sometimes I would distinguish between:
1) how other classes access the constants
2) how you maintain the constants
If you have a lot of constants that could require maintenance (e.g. internationalized GUI text) then you might want to do a bit of both approaches:
- the Java constant exists in the most appropriate class (which is good OO practice)
- the value for that constant is retrieved from a single property file.
So for example you'll have classes like:
class A {
static final int CONST_A=Util.fetchIntProp("A");
class B {
static final String CONST_B=Util.fetchStringProp("B");
final class Util {
private Util() {}
static int fetchIntProp(String name) {
// getting resource or reading property, etc.
// etc.
[ May 01, 2002: Message edited by: Reid M. Pinchback ]

Reid - SCJP2 (April 2002)
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Ok, maybe it is better and more OO to have constants in their own classes. I think this will make also javadocs easier to read. I just have to think for every constant should they be public, protected, private, or with package visibility.
Thank you all of you for your valuable advice.
I agree. Here's the link:
subject: About constants
It's not a secret anymore!