5 ms·
> Managing code decorated with Java getters and setters is hell and complicated. The lack of a meaningful solution to the problem of getters and setters is just
by TheFreim 4y ago
> Managing code decorated with Java getters and setters is hell and complicated. The lack of a meaningful solution to the problem of getters and setters is just the tip of the iceberg.
I don't use Java much these days, is this a huge issue still? Back when I used to do a bit of light java, mainly dealing with minecraft server plugins, almost everyone used lombok which seemed to do the job.
- adam_arthur 4y agoThere are libraries like Lombok that will generate the getters/setters for you via annotations. But tbh still feels very cludgy. Why not add some first class immutable structure syntax to avoid need for getters/setters at all. Just so many better languages to choose from these days, Java is too far behind. And where they bridge the gap, they tend to do it in an awkward way.
- namero999 4y agoJava has records.
- adam_arthur 4y agoNews to me! Nice to see for sure, but doesn’t invalidate the overall point. Most of these bridge features are hobbled by BC concerns. E.g lambdas, generics
- sidpatil 4y agoI believe Java also got record classes, beginning with version 14.
- Shorel 4y agoJust the idea of writing getters and setters that don't actually do anything at all, except to allow access to a 'private' variable, makes me want to tear my hair. It's boilerplate for the sake of boilerplate.
- marginalia_nu 4y agoMaybe I'm not seeing it, but if you want public access to a private variable, why not set it to public? Just saying. I code primarily in Java, and I can't really say the last thing I wrote a getter or a setter, except possibly because I wanted a functional reference. Accessor methods is part of a style of code Java that was unfashionably outdated 10 years ago.
- OkayPhysicist 4y agoThe language design failure that get/set methods are used to monkey patch around is the lack of computed properties. If you have an object with properties A and B, but later realize that B can be calculated from A, it would be nice to eliminate the class of "Inconsistent A and B Values" bugs from your software, by making B calculated from the value of A. The problem is, without computed properties, that involves replacing the Object.B expressions with Object.getB() expressions, breaking your API. So Java developers got in the habit of putting getters and setters on everything.
- marginalia_nu 4y agoI don't think that rationale makes a lick of sense in code written today. Besides the obvious violation of the YAGNI-principle and stinky mixture of data and logic, even if this scenario arises (which it very rarely does) any Java IDE worth its salt can replace a variable access with a method with a few mouse clicks. Now, in 1995, maybe...
- ivanche 4y agoThat is very broad generalization. I have a habit of never writing them unless I'm forced to do it.
- ivanche 4y agoExactly! And the solution is don't write getters and setters unless you are absolutely forced to do so, and even then only for the minimum amount of fields.
- pie_flavor 4y agoLombok requires undocumented compiler internals, and explicit IDE support. There is thus functionally no difference between Java with Lombok and a separate language, at which point there's no reason to not use Kotlin directly.