Xjyuk

I am not looking for an opinion about semantics but simply for a case where having getters sensibly used is an actual impediment. Maybe it throws me into a never-ending spiral of relying on them, maybe the alternative is cleaner and handles getters automatically, etc. Something concrete.

I've heard all the arguments, I've heard that they're bad because they force you into treating objects as data sources, that they violate an object's "pure state" of "don't give out too much but be prepared to accept a lot".

But absolutely no sensible reason for why a getData is a bad thing, in fact, a few people argued that it's a lot about semantics, getters as fine per-se, but just don't name them getX, to me, this is at least funny.

What is one thing, without opinions, that will break if I use getters sensibly and for data that clearly the object's integrity doesn't break if it puts it out?

Of course that allowing a getter for a string that's used to encrypt something is beyond dumb, but I'm talking about data that your system needs to function. Maybe your data is pulled through a Provider from the object, but, still, the object still needs to allow the Provider to do a $provider[$object]->getData, there's no way around it.

Why I'm asking: To me, getters, when used sensibly and on data that is treated as "safe" are god-sent, 99% of my getters are used to identify the object, as in, I ask, through code Object, what is your name? Object, what is your identifier?, anyone working with an object should know these things about an object, because nearly everything about programming is identity and who else knows better what it is than the object itself? So I fail to see any real issues unless you're a purist.

I've looked at all the StackOverflow questions about "why getters / setters" are bad and though I agree that setters are really bad in 99% of the cases, getters don't have to be treated the same just because they rhyme.

A setter will compromise your object's identity and make it very hard to debug who's changing the data, but a getter is doing nothing.

You can't write good code without getters.

The reason why isn't because getters don't break encapsulation, they do. It isn't because getters don't tempt people to not bother following OOP and putting methods with the data they act on together. They do. No you need getters because of boundaries.

The ideas of encapsulation and keeping methods together with the data they act on simply don't work when you run into a boundary that keeps you from moving a method and so forces you to move data.

It's really that simple. If you use getters when there is no boundary you end up having no real objects. Everything starts to tend to the procedural. Which works as well as it ever did.

True OOP isn't something you can spread everywhere. It only works within those boundaries.

Those boundaries aren't razor thin. They have code in them. That code can't be OOP. It can't be functional either. No this code has our ideals stripped from it so it can deal with harsh reality.

Michael Fetters called this code fascia after that white connective tissue that holds sections of an orange together.

This is a wonderful way to think about it. It explains why it's ok to have both kinds of code together. Without this perspective many new programmers cling to their ideals hard, then have their hearts broken and give up on these ideals when they hit their first boundary.

The ideals only work in their proper place. Don't give up on them just because they don't work everywhere. Use them where they work. That place is the juicy part that the fascia protects.

A simple example of a boundary is a collection. This holds something and has no idea what it is. How could a collection designer possibly move the behavioral functionality of the held object into the collection when they have no idea what it's going to be holding? You can't. You're up against a boundary. Which is why collections have getters.

Now if you did know, you could move that behavior, and avoid moving state. When you do know, you should. You just don't always know.

Some people just call this being pragmatic. And it is. But it's nice to know why we have to be pragmatic.

Getters violate the Hollywood Principle ("Don't call us, we'll call you")

The Hollywood Principle (aka Inversion of Control) states that you don't call into library code to get things done; rather, the framework calls your code. Because the framework controls things, broadcasting its internal state to its clients is not necessary. You don't need to know.

In its most insidious form, violating the Hollywood Principle means that you're using a getter to obtain information about the state of a class, and then making decisions about which methods to call on that class based on the value that you obtain. it's violation of encapsulation at its finest.

Using a getter implies that you need that value, when you actually don't.

You might actually need that performance improvement

In extreme cases of lightweight objects that must have the maximum possible performance, it's possible (though extremely unlikely) that you can't pay the very small performance penalty that a getter imposes. This won't happen 99.9 percent of the time.