'public static final' or 'private stat

2019-01-30 06:08发布

问题:

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?

回答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.



回答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.



回答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.



回答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".



回答5:

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



回答6:

The advantage of using setter and getter on member is to be able to overwrite. This is not valid for static "methods" (rather functions)

There also no way to define interfaces static methods.

I would go with the field access



回答7:

I'd stay with the getFoo() since it allows you to change the implementation in the future without changing the client code. As @Tomasz noted, the JVM will probably inline your current implementation, so you pay much of a performance penalty.