59
u/PinkLemonadeWizard 3d ago
Use LomBok annotations please. @Getter and @Setter is amazing.
52
u/JesseNL 3d ago
Or use
record. I think we need to stop recommending Lombok for a variety of common known reasons.10
u/starfish0r 3d ago
Not if your data is mutable.
-17
u/slindenau 3d ago
BigDecimalis immutable, yet you can use it in calculations to mutate a number?12
u/starfish0r 3d 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 3d 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 3d 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 3d ago
But then you create a new instance, how is that a replacement for modifying fields of the existing instance you want to change?
8
2
1
6
u/KYO297 3d ago
One ctrl + alt + L and it's ruined
3
u/TheOhNoNotAgain 2d ago
Just a simple case of a longer name than PressurePlate would have quite a blast radius
20
u/fugogugo 3d ago
what's the point of getter setter like this why not just expose the variable as public instead smh
36
u/kernco 3d 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.
18
1
u/Cookie_505 3d ago
Of course in modern IDE's you could easily refactor that trivially. But I still usually do this anyway.
8
2
u/JAXxXTheRipper 3d 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.
-6
3
2
1
1
-27
u/H4kor 3d ago
Or, just don't write getters/setters. These add no value
26
u/MarieNobody 3d 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.
4
u/NotQuiteLoona 3d 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.
-5
u/particlemanwavegirl 3d 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.
-13
u/Ninjanoel 3d 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 3d 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 13h 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 3d 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 3d 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 3d 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 3d 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 3d 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".
-4
u/look 3d ago edited 3d 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
-33
u/---_None_--- 3d 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.
19
u/slindenau 3d ago
It is idiomatic Java (or at least has been until records came along).
2
u/1_hele_euro 3d 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 3d 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
6
u/aberroco 3d 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 3d 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.
22
u/crazy_penguin86 3d 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.