The less objects know about each other, and the more data and associated behaviour can be internalised within objects, the less coupling there’ll be between objects and therefore the easier it will be to make a change to one class without impacting on other classes.

“Don’t use getters and setters” is no more a design insight than “singletons are bad” or “use dependency injection”.

Objects have to share data. Otherwise you would have to put everything in one class. The goal is to minimise the amount of sharing and maximise the internal cohesion of classes. Not to do away with accessor methods.

The more general case is to “tell, don’t ask” and not enquire about the properties of objects at all.

Implementation hiding

It might look like a field of a class is only there to hold a value, but down the road, you might want to add validation to the setter or a different type of getter (calculated from another value or retrieved from a database).

Many IDEs will generate your getters/setters for you.

But what do getters/setters hide? Sometimes they hide validation. Sometimes they hide construction or retrieval of the property from somewhere else. Sometimes they hide a calculation. Sometimes they throw an exception if the argument isn’t valid. Right now they might just be doing a “return myInt;”, but tomorrow I may change that method to do something more complicated and then I don’t have to go out and change the 50 different other classes that call the setter/getter.

Then there is the cases where:

a) You are using IOC/DI to set the properties in something like a Spring bean.
b) You are using something like iBatis where setters/getters are the convention for creating some bean from some mapped SQL.
c) You are implementing an interface where maybe someone else wants to add a proxy via AOP to wrap the getter/setter with additional code (validation, etc.)