CODEWITHSUNDEEP
java
Vivart
Vivart

Reputation: 15313

Creating class for defining constants

Most of the time I define constants in the same class where i want to use them.

But now i have to define all common constants in a separate class. I have seen two version of constants defining classes:

a. It will give compile time error, if you try to create object of Consts.

final class Consts  {
        private Consts(){}

        public static final String TAG = "something";
    }

b. If will throw a run time exception, if you try to create a object of Consts.

 final class Consts  {
        public Consts(){
            throw new RuntimeException();
        }

        public static final String TAG = "something";
    }

check this class of android http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/android/Manifest.java Why they have used second version?

Which one should I use and why should I go for second version?

Upvotes: 0

Views: 198

Answers (3)

Sebastian Zarnekow
Sebastian Zarnekow

Reputation: 6729

From my point of view, there is no reason to use the second approach. It is misleading from the API since the class exposes a visible constructor that will throw an exception in any case. Clients may fall into that trap.

However, there are other options, too, e.g. you could make Consts an interface

interface Consts {
  String TAG = "somthing"
}

This would allow for classes that implement the interface and thereby have "easier" access to the constants (without static imports). Another advantage would be, that you could use find references even if you only have the compiled classes in your IDE. Since the compiler will inline the constants into the using classes, references to TAG are hard to find. If the clients implement that interface, they can be easily lookup up. However, some coding guidline forbid that.

The next option that is possible, would be an enum. The JVM will ensure that there is only one instance for each constant in an enum class:

enum Consts {
    TAG, OTHER, ..
}

Upvotes: 1

gd1
gd1

Reputation: 11403

You can use both, first is simpler and better because causes 'compile' errors, not runtime, i.e. you catch the problem before.

You can also make the class private in the package (not using the public modifier) and write the other classes in the package (if it's always you writing them) so that they don't instantiate that class. Yes, java is OOP, but you don't need to be pedantic. :) I've never seen anybody instantiating a class of static fields by mistake, and if he/she does, than it makes no harm.

Upvotes: 1

Joachim Sauer
Joachim Sauer

Reputation: 308001

I don't see any reason for the second version, as the first one (private constructor) does exactly what you want.

Another common idom is to make the constant-holder an interface. However, this is not universally appreciated and can lead to people implement-ing that interface, which is often considered a code smell.

Upvotes: 3

Related Questions