The basic “private field with public getter and setter that do nothing but return or set the field” pattern is indeed completely pointless when it comes to encapsulation, except that it gives you a chance to change it later without changing the API.
So don’t use that pattern unthinkingly. Carefully consider what operations you actually need.
The real point of getters and setters is that you should only use them where they are appropriate, and that they can do more than just get and set fields.
- You can have only a getter. Then the property is read only. This should actually be the most common case.
- You can have only a setter, making the property configurable, but communicating that nothing else should depend on its value
- A getter can compute a value from several fields rather than return one field.
- A getter can make a defensive copy
- A getter can perform an expensive fetch operation lazily and use a field to cache the value
- A setter can do sanity checks and throw
IllegalArgumentException - A setter can notify listeners of changes to the value
- You can have a setter that sets multiple fields together because they belong together conceptually. This doesn’t adhere to the JavaBeans specification, so don’t do it if you depend on frameworks or tools that expect JavaBeans. Otherwise, it’s a useful option.
All of these things are implementation details that are hidden behind the simple “getter and setter” interface. That’s what encapsulation is about.