Difference between "public static" and "private static" for storing simple data. What is better?

Question

What is a better solution?

I was thinking about that, what is actually better on performance, or which is more "correct"?

public static List<String> globalUseVariable;

or

private static List<String> globalUseVariable;
public static List<String> getGlobalUseVariable() {
    return globalUseVariable;
}

I think the second one because of encapsulation rule?

Answer 1

Simply spoken:

• Avoid static in the first place
• Avoid exposing internal state, too

Having a public writable field is almost a no-go. If you allow multiple components to update that data, then that leads to direct, hard coupling. And it also means that you can (most likely) say "good bye" to thread safety. And even when you think "I will only read that field today"; maybe you forget about that in a few weeks. Or somebody else on your team misses that part. So

So, if you have good reasons to make some data available to the "public"; then at least use a getter method; as that allows for (later) changes. Or it allows for simple enhancements like returning a copy/clone of the internal state (to prevent "outsiders" of manipulating that internal state later on).

Two ways to get around static:

1. Think long and hard if you really need global state, or something else could do the job
2. If you need global state, then: A) create an interface that denotes the service you want to put up B) create an implementation of that interface as a "normal" class C) then use a singleton (for example an enum) that implements that interface too [ and now the singleton enum can delegate its work to that impl class ]

By following approach 2, you get something that gives you the same functionality (you have a "global" thing that all code can use); but you keep things more decoupled; and most important: you can do reasonable unit-testing all over the place.

static is very often a "killer" for reasonable unit-testing.

Answer 2

Using getters is advised because there is a chance that you will want to make changes to the class without changing the API or that you will decide that some kind of a conversion should be performed before returning the list. Have a look at this answer regarding a similar situation. In my opinion the same principle generally applies to static fields, there is really no reason to make an exception for them. This question also touches the same topic. I think that the reasons outlined there apply to the static fields as well and are completely reasonable.

In general if you make something public you create a public API and should guarantee that it is unlikely to change to save yourself from a major headache later on (and changes might even be impossible if you are creating a public library and have to be backwards-compatibile).

Additionally using getters and setters you can ensure that the code you write will be thread secure, as mentioned in the other answers and the linked questions. You can't do anything about it when you expose public fields.

Answer 3

which is more "correct"?

As your code stands, I agree with neither. You gain nothing from marking your List as private and then returning a reference to the same List within a method. You can't call this encapsulation because no matter what logic you add inside the method, you are returning the List reference back to the caller to modify as they please. The least you can do is ask your method to return an unmodifiable collection (using Collections.unmodifiableList) if you want to truly adhere to encapsulation.

If you want your list to be public, the least you can do is mark it as final so that code outside your class cannot attempt something like YourClass.globalUseVariable=null and break any code that uses the List.