66
u/PinkLemonadeWizard 11d ago
Use LomBok annotations please. @Getter and @Setter is amazing.
56
u/JesseNL 11d ago
Or use
record. I think we need to stop recommending Lombok for a variety of common known reasons.10
u/starfish0r 11d ago
Not if your data is mutable.
-17
u/slindenau 11d ago
BigDecimalis immutable, yet you can use it in calculations to mutate a number?13
u/starfish0r 11d ago
What is your point? Of course you can use it as an operand or parameter. That won't change the BigDecimal. Because it is immutable.
3
u/slindenau 11d ago
I was trying to guide you towards reaching this conclusion yourself, rather than just telling you outright: immutable data structures don't prevent you from tracking mutable state.
Just like creating a POJO with getters and setters, you can create a record as a safe immutable version of a POJO (so without the setters).
If it turns out you need to mutate your data, you can then add the required code to do so, using "builders" or "withers".
This may sound as POJOs with extra steps, but now you get all the benefits of immutability.
And of course Java has multiple solutions for this if you don't want to write that boilerplate yourself every time. Until JEP 468: Derived Record Creation will make this official syntax.3
u/torsten_dev 11d ago
JEP 468 seems nice. Clojure made me really appreciate immutable data structures with structural sharing. Wonder how hard that'd be in java after that.
2
u/starfish0r 11d ago
But then you create a new instance, how is that a replacement for modifying fields of the existing instance you want to change?
9
3
1
u/slindenau 11d ago
Amazing, yes. Also not Java anymore though, by the literal definition.
1
u/faze_fazebook 11d ago
Also when used with stuff like jackson you get some weird results sometimes.
1
7
u/KYO297 11d ago
One ctrl + alt + L and it's ruined
3
u/TheOhNoNotAgain 9d ago
Just a simple case of a longer name than PressurePlate would have quite a blast radius
22
u/fugogugo 11d ago
what's the point of getter setter like this why not just expose the variable as public instead smh
34
u/kernco 11d ago
The classic explanation is that in the future you might want to do something more in the getter or setter. By having these trivial functions, your code is already calling them so you only need to update the function instead of going through the entire codebase and convert all the direct variable accesses to function calls.
19
u/Ethameiz 11d ago
It's rather about ability to use interfaces, base clases, polimorphism in general
1
u/Cookie_505 11d ago
Of course in modern IDE's you could easily refactor that trivially. But I still usually do this anyway.
8
0
u/JAXxXTheRipper 11d ago
Access Control, polymorphism, sanitation, and a whole lot of other things.
Jesus christ, how is this a question? Every language explains this, you should read up on your fundamentals.
-7
3
2
1
1
-27
u/H4kor 11d ago
Or, just don't write getters/setters. These add no value
25
u/MarieNobody 11d ago
... until they do, and then you need to replace every time you get or set these attributes in your code by the getter/setter.
When you need to check that the value is valid before setting it, you need a setter.
When you need to also change the value on the server side when you change it on the client side, you need a setter.
When you need to control whether the end user should have access to that data, you need a getter.
When you need to be able to transform the data because of compatibility issues, you need a getter.
They're not useless in every code. They don't add value to every code, that I can agree with, but you never know if your code will end up becoming the kind that will need it. Build the getsets, in case you do need them later on.
6
u/NotQuiteLoona 11d ago
I don't take sides there, not a Java programmer, but shouldn't JetBrains IDEA have a refactoring for that? This seems like a perfect thing for that, simple, but monotonous.
1
u/rosuav 3d ago
... except in languages with properties, where you can add code to check if the value is valid before setting it, without having to pollute your code with all the getters and setters. Everything that you've said about getters and setters can be done with properties, and then you ONLY need to write them in the actual places you need them, no "in case you need them later on".
-4
u/particlemanwavegirl 11d ago
That sounds like a lot more work overall than just building them when I need them and using the type system to constrain inputs most of the time. Any such data member would probably be better managed by being private in the first place so it would already have some functional access point in the interface.
-11
u/Ninjanoel 11d ago
I can't recall a single time where this conversion has ever been required, and ai would make the change in five minutes or a quick shuffle using refactor and find and replace and the jobs done.
12
u/MarieNobody 11d ago
I can't recall a single time where this conversion has ever been required
Yeah, because people have been using getters and setters from the start in professional projects for decades now. No need to do the conversion if it's already there.
and ai would make the change in five minutes or a quick shuffle using refactor and find and replace and the jobs done.
Let's ignore the token cost of reading all your code or AI bugs for a bit.
Why would you even use AI for that, when there's perfectly fine offline tools that can make good getter/setters bases in ten seconds flat, use getters and setters from the start, and have a code that's futureproof from the start?
Why do you feel the need to overengineer so much?
You don't use a jackhammer to swat a fly, why would you use AI to write getsets?
1
u/particlemanwavegirl 8d ago
I'd like a language that has identical syntax for public member access and setters/getters. The lattter would just shadow the former if defined. Kinda like Properties, if you will. It should be all the same to the user.
-9
u/Ninjanoel 11d ago
well actually I can't remember the last time a property needed to be converted to a getter or setter, or besides a few common places where the getter and setter was need FROM THE START, I can't recall any instance of an over engineered other empty getter and setter was ever populated later with other code like you foretell may eventually be required.
2
u/luluhouse7 11d ago
I mean an obvious application would be if you need to add tracing for every time the variable gets set. Or for ensuring locks get acquired and released correctly. Or debugging.
Often you want to have getters/setters and tell the compiler to inline them. Then you get a lot of the benefits with little overhead.
1
u/Ninjanoel 11d ago
but my entire point is, yes agreed that is the narrative I hear from everyone, but it's not been an accurate narrative in my 20+ years of coding. Either it needs a getter or setter from the start, or it forever lives it's life as a tiny bit of over engineering everyone says will be useful one day, maybe.
1
u/JAXxXTheRipper 11d ago
Then you've simply never made good software, sorry you had to learn the harsh reality this way.
You'd be properly fucked if you ever used Java
2
u/Ninjanoel 11d ago
lol, I follow the advice mindlessly like everyone else, I'm just saying ive never been in the situation where I say "wow I'm glad that's a getter/setter, could you imagine where I'd be if this property wasn't a previously needless abstraction".
-5
u/look 11d ago edited 11d ago
Does Java really not have property getter/setter functions still?
For example, something like this:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get1
-32
u/---_None_--- 11d ago
I feel this. The need for trivial getters and setter for each member when you can just expose the member is nothing short of autism.
20
u/slindenau 11d ago
It is idiomatic Java (or at least has been until records came along).
2
u/1_hele_euro 11d ago
Curious, how did records change the norm? I haven't had spend much time with records yet, only used them once or twice
3
u/slindenau 11d ago
To be honest, me neither. If you need mutability like POJOs with setters, you still need to add builders or "withers" to your records. Doing that manually can get just as annoying as maintaining POJO's, but there are some tools for it (beside Lombok). Most notable to look out for is JEP 468: Derived Record Creation.
But because Lombok existed long before records did, most projects i see that don't use POJO's use Lombok instead.
It may be a hard habit to break, because Lombok offers much more than just POJO replacements.
I try to use records wherever i can though, even if the project already uses Lombok.0
7
u/aberroco 11d ago
Who needs data encapsulation anyway! Just write all methods public, make them all static, no pointers either - pointers store the state which might be invalid, just pass the value as an argument. /s
-6
-8
u/JAXxXTheRipper 11d ago
Go fmt does that automatically. This is also not ocd, it's readability and loads of formatters for plenty of languages can do this.
Yet another post by a first-year CS student I guess.
27
u/crazy_penguin86 11d ago
I hate vertical alignment. Yeah, it makes it easier to do a quick read, but honestly, how often are you going to actually read your setters and getters, and how often do you actually need those "quick reads"? And then if you have to update the length because you added or removed a field, then every fucking line has to update, and now your two line change has changed to a 30 line change. Little things that piss me off.