Data Classes for Java
cr.openjdk.java.net
Data Classes for Java
1–10 of 216 posts
Re: Data Classes for Java
#2... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ...
If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it.
I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the level of plain data, then just make a class with public fields and no methods. If you're trying to write a 'higher level' object - then don't refer to the names of fields in your method names. The getter/setter/property approach is just the worst of both worlds. They make explicit reference to an objects internal fields, while at the same time obfuscating what happens when you actually access them.
Re: Data Classes for Java
#3I, for one, am enjoying the ever so slow scalaization of java.
Re: Data Classes for Java
#4... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
While I mostly agree, getters without setters is a nice way to expose that youre data is immutable rather than relying on final fields
Re: Data Classes for Java
#5Or just install Lombok.
Re: Data Classes for Java
#6Honestly immutable data classes that are created via builders is a must have in Java.
Re: Data Classes for Java
#7I, for one, am enjoying the ever so slow scalaization of java.
If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit.
Besides maybe Rust. Really different usecases though.
Re: Data Classes for Java
#8... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
You're cutting out/ignoring a big chunk of the quote and then arguing a point the author didn't make. Simply accessing properties directly doesn't solve the problem.
Re: Data Classes for Java
#9... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
You'll get you run out of town with that level of heresy in most java/c# shops. Getters and Setters are great when you want finer control over what can access certain fields, in a List class for instance, I wouldn't want the length to be externally writable. But somewhere along the way it went from a useful feature in some circumstances to a mandatory feature in all circumstances.
In the c# world "public int Id;" will fail code review but "public int Id { get; set; }" will be just fine. I've never seen a justification for it though, if we make a change in future it's going to take just as much work and 99.99% of the time will never be required.
But we have to appease the encapsulation gods.
Re: Data Classes for Java
#10... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
> obfuscating what happens when you actually access them
This is the point, AFAICT. In languages with both primitive "read/write field" operations that can't be interceded upon, but also with interfaces/protocols, "obfuscating" (encapsulating) a field access in getter/setter methods is how you allow for alternative implementations of the interface/protocol.
Specifying your object's interface in terms of getters/setters allows for objects that satisfy your interface but which might:
• read from another object (flyweight pattern)
• read from another object and return an altered value (decorator pattern)[1]
• read from an object in a remote VM over a distribution protocol (proxy pattern)
Etc.
Then a client can build these things and feed them to your library, and you won't know that they're any different than your "ordinary" data objects.
You don't see this in languages with "pure" message-passing OOP, like Ruby or Smalltalk, because there's no (exposed) primitive for field access. All field access—at the AST level—goes through an implicit getter/setter, and so all field access can be redefined. But in a language like Java, where field access has its own semantics divorced from function calls, you need getters/setters to achieve a similar effect.
And yes, this can cause problems—e.g. making expected O(1) accesses into O(N) accesses, or causing synchronous caller methods to block/yield. This is why languages like Elixir, despite having dynamic-dispatch features, have chosen to discourage dynamic dispatch: it allows someone reading the code to be sure, from the particular function being called, what its time-and-space-complexity is. You know when you call MapSet.fetch that you're getting O(1) behaviour, and when you call Enum.fetch that you're not—rather than just accessing MapSets through the Enum API and having them "magically" be O(1) instead of O(N).)
---
[1] Which is a failure of the Open-Closed Principle. That doesn't stop people.