4 ms·
And the second you have anything other than a toy application you'll find out why getters, setters, and validation were invented, and why we them just moved eve
by happymellon 8mo ago
And the second you have anything other than a toy application you'll find out why getters, setters, and validation were invented, and why we them just moved everything to have consistent interfaces.
- tadfisher 8mo agoThis is the meme where the Padawan exposes public fields, the intermediate says you must use setters and getters, and the Jedi just exposes public fields. (Records kind of made this moot, and for the better)
- happymellon 8mo agoExcept records are immutable and have getters and setters as builtins to replicate what we've been doing with Lombok. So enforces what I was saying.
- throwA29B 8mo ago>immutable >setters sigh
- brunoborges 8mo agoTo be clear, Records don't have setters. They are immutable.
- happymellon 8mo agoYeah, sorry, typo. Still they institutionalise getters, which is the opposite of what their argument was.
- tadfisher 8mo agoWell, they don't have "getters" either, they have accessors; x() instead of getX(). It's still bad, but at least it doesn't enforce JavaBeans conventions, which is where getters and setters actually originate [0]. 0: https://en.wikipedia.org/wiki/JavaBeans https://en.wikipedia.org/wiki/JavaBeans
- dwroberts 8mo agoI think getters and setters had more value when IDEs and refactoring tools were worse (or non-existent). A free-for-all accessing some public field is now less of a risk because it’s trivial to find all references and change them.
- jghn 8mo agoHave worked on many a non-toy java application. Have never used things like Lombok hiding getters/setters behind the covers. Never found this to be a real world problem.