> That's exactly the point. This whole data-hiding thing has way too many downsides.
The usual argument against OOP that I hear is that implementation inheritance is brittle. That, I understand and agree with.
But data hiding being bad? I'm not persuaded. The whole divide-and-conquer aspect of breaking modules into smaller parts requires not exposing unnecessary details as interfaces.
You have a starter motor in a car. If it's only connected to the motor via a couple wires, then it's easy to design a better one and install it. But if it has dozens of wires connecting to every which part of the engine, improving it is much harder.
> Also in most web apps: Your data will escape your precious objects (mostly as JSON).
My "precious objects"? :( Can we please discuss this subject without getting into a flamewar?
Well, will your data escape or not?
As long as you are staying in OOP-land, everything is as it should be: Objects passing messages to each other, as politely as possible (trying not to bring in the concurrency aspect)
But then, there comes a REST endpoint around and wants your data. Now it is out in the open and subject to inspection and change.
So what have you gained by using data-hiding? Shouldn't you be able to pass that data around openly in the rest of your code as well?
Maybe I shouldn't say data. I should say values. Immutable ones.
Values can be passed around safely. They can be inspected by anyone. Accessed by multiple threads etc.
That allows for abstractions that are impossible to achieve with stateful objects.
In OOP we keep our state hidden in the objects, have methods manipulate it, but that means these object can't be a value. They can change anytime. You can't even observe those state transitions (unless you code for them, which gave us bean-style properties...)
To stay with your motor example: If you assemble a motor from values and start it, it will continue to work, even if someone installs a new part.
You can't break the motor.
You can even save the motor to disk at any time, load it back and you still have a working motor.
Yes, all of this could be achieved by using objects talking to each other, but it is vastly more difficult (try to snapshot a consistent state of an object graph, for example)
The usual argument against OOP that I hear is that implementation inheritance is brittle. That, I understand and agree with.
But data hiding being bad? I'm not persuaded. The whole divide-and-conquer aspect of breaking modules into smaller parts requires not exposing unnecessary details as interfaces.
You have a starter motor in a car. If it's only connected to the motor via a couple wires, then it's easy to design a better one and install it. But if it has dozens of wires connecting to every which part of the engine, improving it is much harder.
> Also in most web apps: Your data will escape your precious objects (mostly as JSON).
My "precious objects"? :( Can we please discuss this subject without getting into a flamewar?