I was looking into an open-source game framework project written in Java. It has several classes that:
- Have public instance variables.
- Have getter/setters for such variables.
Generally, I write getters/setters when I want to encapsulate some behavior that occurs when a property is modified.
However, looking at the code, it literally goes something like this:
public class Test {
public int value;
public void setValue(x) {
value = x;
}
public void getValue() {
return value;
}
}
Then I thought about checking out the rest of the framework and see how do they modify such value, which may give me a hint on why did they do the above.
From what I’ve seen, they do it like this:
object.value = 100;
Without using the getters/setters.
So now I’m not sure what was the point of creating getters/setters.
So, my question is, is there a reason I would want to create getters/setters for a public value, if such getters/setters don’t even implement any kind of special behaviour?
It sounds like the authors of the class were confused or changed their minds half-way through writing it. In most cases, public attributes are a ‘bad thing’, and public accessors are the way to go: they allow the class to change the implementation and even reject the operation. In short, to protect its own internal state.
2
In a number of languages, classes can expose fields, but interfaces cannot. In some cases, it may be useful to a class expose information via both its class type (in which case consumers could uses fields) and via an interface (in which case consumers must use methods).
For example, a Location3d interface might define methods getX(), getY(), and getZ(). A Point3d class might define fields X, Y, Z and also implement that interface. Other objects which have locations, but don’t store the X, Y, and Z directly, might implement the interface to allow other entities to inquire about their position.
Continuing the example, a Monster class in a game might expose an EnemyLocation which holds a reference back to the monster, and implements getX() etc. methods so they will continuously report the location of the monster’s current enemy. If the EnemyLocation stored coordinates directly, or even if it held a reference to the current enemy’s Point3d, the coordinates wouldn’t get updated when a monster finds a new enemy to target. If, however, its getX() etc. methods examine the attached monster, and read the present location of that monster’s present enemy, they can always report up-to-date data.
3
I would guess the two most likely reasons are:
- That the getters and setters were autogenerated by the authours tooling.
- The variable was initial set to be a more restricted scope and someone else has changed it.
Not sure why you’d have a public member, unless it was static, const, readonly, etc.
I think public properties should always be preferred to public members; if you need to make changes to a public member, or whatever reason, it will mean any extant calls outside the class would need to be updated. Properties offer another layer to change things internally without (hopefully) having an impact outside of the class.
Supercat also makes an excellent point about interfaces.