Java OOP – Private Static vs. Public Static

javaobject-oriented

A wrapper class for storing primitive parameters which are initialized with values. Is it better to use public static or private static with bunch of getters and setters, for these constants?

public class Wrapper {
  // This
  private static int PARAMETER = 100;

  /** 
   * EDIT:
   * public int getParameter();
   * public void setParameter(int n);
   * Pointed out by @JimmyJames that I forgot the static accessor.
   */

  public static int getParameter();
  public static void setParameter();

  // Or this?
  public static int ANOTHER_PARAMETER = 200;
}

My observations:
1. These parameter are rarely changed.
2. I feel like it reduces readability when there are a lot of these parameters, if using private static with lots of getters and setters.

Any thoughts on which one is better? Maybe depending on different scenarios?

Thanks.

EDIT
Pointed out by @JimmyJames that I missed the static accessor on the methods.

I do not think this is related to my question. I should probably phrase my question better, these PARAMETER are more likeCONSTANTS, making them static or even final makes things easier to access directly like doOperation(Wrapper.ANOTHER_PARAMETER) or doOperation(Wrapper.getParameter()).

After reading comments and answer of @Robert Harvey and @JimmyJames, and other readings, I think essentially this is a bad practice that should be avoided (using class to hold constants).
Where do you keep Constants used throughout your application?

MORE QUESTION
What if there are moderate amounts of PARAMETERS/CONSTANTS that are used across a module and they cannot be pinpointed to specific classes, at this time should we consider grouping all these together in a class, and access them through the methods mentioned above(as they will be available when class is loaded)?

Best Answer

There's a major problem with the first approach you are showing here. You have static variables but your methods are not static. This is very abnormal in Java and will create a lot of confusion if you are working on a team. It also has some really negative implications if you ever need to multi-thread. Even in a single-threaded app, you could see instabilities if you are not extremely careful. You should some spend time up-front creating robust classes so that you don't incur the cost of having to be careful with how you use them later.

The problem here is that this class needs to be instantiated in order for you to set the class-level variables variables. But there's nothing here preventing more than one instantiation of this class. You could have any number of these objects around and calling a set method will change the value returned by get for all the other instances. This is not typically expected. When you create a object and modify a property, the normal pattern is for it to only change that object.

To resolve this, you could make the getter and setter static. This will make it work in a more expected manner. But as Robert Harvey noted in his comment, using static in this way is widely discouraged. Effectively, you will have created global variables (with some minor caveats.) I'm not going to explain why globals are problematic here as there are many articles and answers about that topic already.

The more popular option here is to (again as mentioned by Robert Harvey) create a normal Java object that you then pass to things that need these parameters. This can be done in code or using various injection frameworks.

Related Topic