Hacker News new | ask | show | jobs
by tempguy9999 2616 days ago
> Getters/setters are technically message-passing methods, but they undermine the design goal because they more or less directly expose internal state to the public world

If they do, that's your fault for letting them. I guess you mean when people chain stuff thus

company.programmers.WebDevs.employ('fred')

where .programmers and .WebDevs is an exposed internal of the company and programmers department respectively? (I've seen lots of this, and in much longer chains too. We all have). In which case please see the Principle of Demeter <https://en.wikipedia.org/wiki/Law_of_Demeter> which says don't do this. Wiki article is good.

I doubt any language can prevent this kind of 'exposing guts' malpractice, it's down to the humans.

I remember reading that Alan Kay said when he saw the Linda model (<https://en.wikipedia.org/wiki/Linda_(coordination_language)>) he said it was closer to what he wanted smalltalk to be.
2 comments
DonaldPShimoda 2615 days ago
> I doubt any language can prevent this kind of 'exposing guts' malpractice

Actually, true OOP languages do prevent this. Internal state is completely private and cannot be exposed externally. The only way to interact with an object's state is through its methods — which means the object itself is responsible for knowing how to manipulate its internal state.

Languages like Java are not "true" OOP in this sense, because they provide the programmer with mechanisms to allow external access to internal state.

Internal state should be kept internal. You shouldn't have a class `Foo` with a private internal `.bar` field and then provide public `Foo.getBar()` and `Foo.setBar()` methods, because you may as well just have made the `.bar` field public in that case.

Also, FWIW, I did not downvote you. I dunno why you were downvoted. Seems you had a legitimate point here, even if I disagree with it.

link
reallydude 2615 days ago
> Internal state should be kept internal.

I'm not sure that's a proven model. It's a proposed model, for sure. Since you can't protect memory from runtime access, you can't really protect state, so it's a matter of convention which Python cleverly baked in (_privatevar access).

link
DonaldPShimoda 2615 days ago
Ah sorry, I was speaking in the context of Kay's OOP! In retrospect my phrasing made it seem like I was stating an opinion as fact, but what I meant was just that Kay's OOP mandated that internal state could not be exposed and was very opinionated on the matter.
link
tempguy9999 2616 days ago
Why downvoted? I don't mind being wrong but would like to know where and why.
link