-1

Possible Duplicate:
How do you define a class of constants in Java?

I would like to define a class in my package to contain only the constant vales like defines in C. I am a C programmer learning Java so perhaps that is why I still want to have some header like class :)

For this purpose here is the class I have:

package com.myclasses
public class defines{

public static byte final ID_1= 0x01;
public static final ID_2= 0x02;

public static String company_name="XYZ";


}

Then somewhere in a another class in the same package, I use these defines as follows:

byte idval = defines.ID_1;

... and so on.

My question is for such a "header" class what is the best way of defining it?

It has only static variables so should I define the class also static?

What about the access modifier? Since it has defines in it I thought it could be made "public".

Please advise.

Community
  • 1
  • 1
user489152
  • 907
  • 1
  • 23
  • 42

4 Answers4

4

This pattern is called the "constant class" pattern (I think).

One way of using it is to make it an interface and implement it, then you get the references for "free":

public interface Defines {
    static byte final ID_1= 0x01;
    static final ID_2= 0x02;
    // etc
}

public class MyClass implements Defines {
    byte idval = ID_1; // Note: No need to refer to the class "Defines" here
}

but most people consider this an anti-pattern, because it isn't a real interface (it has no methods). Nevertheless, it is kind of cool, and may be a good way for you to ease into java.

The "standard" approach is to define a "utility class", which is one that has only static fields and methods, give it a private constructor to reinforce that you shouldn't create one of these. This is what you have done - keep doing it.

If you have a few constants that are different values of "the same thing", eg directions on a compass, etc, strongly consider using an enum. You should read up on them.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • Why would you recommend an anti-pattern when there are better alternatives (enums)? – assylias Jun 04 '12 at 12:44
  • @assylias enums have their place, but sometimes you just need a bunch on constants. – Bohemian Jun 04 '12 at 12:51
  • "a bunch of constants" that you put in an enum. Instead of having to implement the constants class (which admittedly makes little sense), you merely import the constant enum (with a static import for a shorter `idval = ID_1.value()` syntax). I am not really convinced that there are cases where a constants interface would be better. – assylias Jun 04 '12 at 13:04
  • 1
    @assylias I don't really like this answer, but `enum` is not necessarily a superior alternative. Consider `interface Constants { String COLOR="Red" ; double SPEED_OF_SOUND=186000 ; long SIZE_OF_STUFF=1323535;}` The `enum` approach requires that the constants all be of the same type. – emory Jun 04 '12 at 13:33
4

Don't

There are hardly any constants that have value in their own. They only make sense in context. That context is a real class, i.e. a class that has instances (at least one). Declare the constants in that class.

As for the modifiers: reduce the scope as far as possible: Private if only used inside the class where they are declared, public if anybody using the class needs the constants as well.

If you declare more then one constant of same type in one class, think about if a enum makes mores sense.

And yes, constants should be static.

Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
  • Thanks Jens. Should I have any private constructors or would the default do? – user489152 Jun 04 '12 at 13:18
  • The usage of the class should define what constructor it has. If you actually create a class only for the constants (which I advise against) make a private constructor so nobody accidental tries to create an instance. – Jens Schauder Jun 04 '12 at 13:31
1

Use a final class

eg : public final class defines {

         // private constructor     
         private defines() {
         }
     }

The constants should be defined as

public static final <type> constantName = <value>;

Wouldn't recommend enums in this scenario as Enums should be used when we are having constants which are having some relation between them.

Having a utility class like this, is the approach we use in our project to define constants that needs to be accessed across a project.

If you needs the constants only in that certain class then defining them in the class itself will be the best solution. eg:

private static final <type> constantName = <value>;
Unni Kris
  • 3,081
  • 4
  • 35
  • 57
  • an interface is a better option than a final class – John B Jun 04 '12 at 13:12
  • What about private constructor? – user489152 Jun 04 '12 at 13:19
  • how does "final" definition affect the class? and why not static class? – user489152 Jun 04 '12 at 13:21
  • yes it will have a private constructor. updated answer – Unni Kris Jun 04 '12 at 13:22
  • a class defined final cannot be subclassed and it prevents other programmers from subclassing a secure class to invoke insecure methods. we don't want any subclass to change the value of a constant. – Unni Kris Jun 04 '12 at 13:24
  • @JohnB May i know what advantages will an interface have on this approach ? – Unni Kris Jun 04 '12 at 13:29
  • By definition it is not instantiatable so you don't have to provide the private constructor. Also, although this is not recommended, classes can `implement` the interface to get access to the constants without prepending the interface name. – John B Jun 04 '12 at 14:22
  • http://stackoverflow.com/questions/320588/interfaces-with-static-fields-in-java-for-sharing-constants – Unni Kris Jun 07 '12 at 05:37
0

Just use an Interface in Java to define all your Constants..

public interface Const {

String GOVERNMENT = "Government";

String PUBLIC = "Public";

...

}

You can use class also.

manurajhada
  • 5,284
  • 3
  • 24
  • 43