Java: necessity of private variables and return methods [closed]

Question

In code I've seen, some people often use private variables, e.g.

private static int number;

And they usually have access methods such as

public static int returnNumber(){

    return number;

}

But my question is, what's the point? The way I do it is this

int number;

Followed by this when I need to access it

int numberToBeAssigned = someClass.number;

instead of

int numberToBeAssigned = someClass.getNumber();

To me it seems impractical to use accessor methods and private variables, I know what they do, the private variables are only allowed to be accessed by the class in which they are located. I just don't see the necessity for them, when you can just as easily instantialize the class and call upon its member variable when you need it. I'm obviously wrong in my logic, but I would like someone to give a clear example on how private variables along with accessor methods can be utilized.

Thank you

Answer 1

The point of accessors like this is to allow you to redesign the implementation without breaking all the rest of your code. For example, what if you decide later on that number should come from a file? Or should be moved to another class?

If you've limited access to go through an accessor, then you can make changes like these and you only have to change the accessor -- you don't have to change all the other code that depends on it.

Answer 2

This is all about encapsulation. Public fields let any ol' class come along and change your values, and possibly break your invariants. If you have just a public int foo, anyone can set it. If it's a private int foo and you provide a getter, people can only get it. If you provide a getter and setter, then they can do both, but you still have control over it; you can reject a change that would break assumptions the class has to (or wants to) make.

It could be that you don't have any such assumptions in this class right now, but a) you may have some in the future and b) other classes do have those assumptions, and therefore need to protected their private fields, and it's nice to have a consistent way of accessing data (not fields in some cases, getters and setters in others).

Really though, this is about basic OO principles: your class isn't just a blob of state, it's a something which has properties and actions -- and under the hood has state to reflect those actions. So for instance, when you ask for a List's length(), you don't conceptually care whether that's reported back as a cached value or whether the List iterated over its elements and counted them; you just want its length.

Which brings us to the last big point (at least in this answer :) ), which is that a getter and setter can be overriden to take advantage of inheritance, while a field cannot.