Java getter/setter style question

Even within your closed-source package, encapsulation is a good idea.

Imagine that a bunch of classes within your package are accessing a particular property, and you realize that you need to, say, cache that property, or log all access to it, or switch from an actual stored value to a value you generate on-the-fly. You'd have to change a lot of classes that really shouldn't have to change. You're exposing the internal workings of a class to other classes that shouldn't need to know about those inner workings.

I would adhere to a common style (and in this case provide setters/getters). Why ?

1. it's good practise for when you work with other people or provide libraries for 3rd parties
2. a lot of Java frameworks assume getter/setter conventions and are tooled to look for these/expose them/interrogate them. If you don't do this, then your Java objects are closed off from these frameworks and libraries.
3. if you use setters/getters, you can easily refactor what's behind them. Just using the fields directly limits your ability to do this.

It's really tempting to adopt a 'just for me' approach, but a lot of conventions are there since stuff leverages off them, and/or are good practise for a reason. I would try and follow these as much as possible.

I don't think a good language should have ANY level of access except private--I'm not sure I see the benefit.

On the other hand, also be careful about getters and setters at all--they have a lot of pitfalls:

• They tend to encourage bad OO design (You generally want to ask your object to do something for you, not act on it's attributes)
• This bad OO design causes code related to your object to be spread around different objects and often leads to duplication.
• setters make your object mutable (something that is always nice to avoid if you can)
• setters and getters expose your internal structures (if you have a getter for an int, it's difficult to later change that to a double--you have to touch every place it was accessed and make sure it can handle a double without overflowing/causing an error, if you had just asked your object to manipulate the value in the first place, the only changes would be internal to your object.