'public static final' or 'private static final' with getter?

Question

In Java, it's taught that variables should be kept private to enable better encapsulation, but what about static constants? This:

public static final int FOO = 5;

Would be equivalent in result to this:

private static final int FOO = 5;
...
public static getFoo() { return FOO; }

But which is better practice?

Solution 1

There's one reason to not use a constant directly in your code.

Assume FOO may change later on (but still stay constant), say to public static final int FOO = 10;. Shouldn't break anything as long as nobody's stupid enough to hardcode the value directly right?

No. The Java compiler will inline constants such as Foo above into the calling code, i.e. someFunc(FooClass.FOO); becomes someFunc(5);. Now if you recompile your library but not the calling code you can end up in surprising situations. That's avoided if you use a function - the JIT will still optimize it just fine, so no real performance hit there.

Solution 2

Since a final variable cannot be changed later if you gonna use it as a global constant just make it public no getter needed.

Solution 3

Getter is pointless here and most likely will be inlined by the JVM. Just stick with public constant.

The idea behind encapsulation is to protect unwanted changes of a variable and hide the internal representation. With constants it doesn't make much sense.

Solution 4

Use the variales outside the class as:

public def FOO:Integer = 5; 

If you encapsulation is not your priority. Otherwise use the second variant so that you expose a method and not the variable.

private static final int FOO = 5;
...
public static getFoo() { return FOO; }

Is also a better practice for code maintenance to not rely on variables. Remember that "premature optimization is the root of all evil".

Solution 5

The first one if the getFoo result is costant and not need to be evaluated at runtime.

View more solutions

Comments

[Voo]

Only if you're absolutely certain you'll never change the final variable though. constants are inlined by the compiler which can lead to extremely surprising results if they change later on and you don't recompile everything. Edit: Figured, that's worth an answer to make it a bit more prominently.

[Adriaan Koster]

Interesting, I never realized this. I never come across constants with getters in the wild though.

[Chris Cummins]

Thanks for the info, it seems then that private constants and getters are empirically safer choices and should be considered better practice.

[Voo]

@Chris Depends on what your constants are - there are lots of constants that are set in stone (Pi for example is quite unlikely to turn out to be 3 after all these years ;) ) so I wouldn't condemn the use of public constants in all cases. But one should keep this in mind, because debugging such a problem is extremely horrible.

[Stephen Hosking]

Wow! +10! I've been in the business for longer than I care to mention, and I've always wondered why I shouldn't just use a public constant when it seems safe to do so!

[Aakash]

It's an old post but still very relevant. IMO constants should never change their value. That's why they are called constants. If there is any field that is used to share it's value across classes, and it's value can be changed, it should not be called constant and should not be treated as such. Java inlining the constants assumes that the value is no going to change. For more info, refer to stackoverflow.com/a/2338074/841221

[袁文涛]

Excuse me, my English is not very good, I didn't see the correct conclusion. Someone told me what the correct answer should be?

[Voo]

@TJ If the "constant" could change in the future use a getter. If the constant will always be the same you can use a public const.