Or just install Lombok.
Lombok @Value for the win!
@Data seems more like what they are proposing. It comes with toString, equals, etc and has a bunch of cool features [0].
Data Classes for Java
101–110 of 216 posts
Re: Data Classes for Java
#102Earlier quoted context omitted.
This is a bit abstract to me. I don't tend to write mutable classes. And if I do mutate fields, it's for a "reason" (and I'll name the method after that reason). If you feel like it, write out how you'd implement the class and why. I posted a fairly strong opinion, but I'm happy to have my mind changed.
Sure, for a simple class like this I would make it immutable too. But the example is just a demonstration of the concept - you should be able to change the implementation without changing the exposed interface. When you first write a class, it may look like a simple bag of fields. But when that inevitably changes, getters and setters allow you to do it without breaking the clients. Even if we keep this immutable, you…
But the example is just a demonstration of the concept - you should be able to change the implementation without changing the exposed interface.
My argument is that having getters and setters exposes your implementation. If you have "getFoo" and "setFoo" it exposes that your class contains a value called Foo. My argument is that you should either give your methods better names, or get rid of the pretense of encapsulation altogether and just make them public. Get/Set is just an awkward middle ground.
Even if we keep this immutable, your implementation is different in that it uses twice as much memory.
How can my implementation be different? No one else has written one (:
But maybe not. If you had getters and setters, you could seamlessly try the other implementation without changing all of the client code.
And if you had actual methods with names that didn't break encapsulation, you could do the same and divorce all your calling code from the burden of knowing about the internal structure. Again, the middling approach is the worst of both worlds to me.
Re: Data Classes for Java
#103Earlier quoted context omitted.
Probably to avoid making 'data' a reserved word and breaking a ton of code that used 'data' as a variable name. Prior to Java 5, 'enum' was a very popular variable name too.
I'm having a difficult time trying to think of a case where "data" is the best variable name for anything.
[deleted]
Re: Data Classes for Java
#104Honestly immutable data classes that are created via builders is a must have in Java.
Make fields public final and your constructor is your "builder".
Those two patterns aren't the same. You can pass around a half constructed builder but you can't pass around a half constructed public final object like you described.
Re: Data Classes for Java
#105Earlier quoted context omitted.
sure, ok, if you only write immutable classes, by definition you never need setters, right? i won't defend mutable classes (i won't decry them either), because i haven't personally thought tons about the benefits of immutability. i mean, i can see a lot of reasons why it's a good thing to shoot for, and i think it's a thing i often try to shoot for. but people often write mutable classes, or must maintain mutable cla…
If you have a mutable class, and you're modifying its fields, you're doing it for a reason, right? Often it's part of a larger operation. So why not name the method that mutates the field after that reason. I got away from thinking about "I am altering the internal representation of this struct + vtable" to "I am sending a message to this opaque thing and I don't really care how it's done when I'm outside the black b…
This seems to deny the fact that a lot of data exists to just be stored and displayed. Probably 85% of all software in the world has a "FirstName" field/property/column in it somewhere. What name you propose giving a method that changes that value?
Re: Data Classes for Java
#106... 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…
I can't speak to Java, but in C#, the original goal was to reduce coupling. You can add behavior to getter and setter methods without breaking binary compatibility among packages. It absolutely is obfuscation, to the extent that encapsulation is just a special kind of obfuscation. Possibly more importantly, public fields give you no way to create immutable types.
> I can't speak to Java, but in C#, the original goal was to reduce coupling.
If you want to reduce coupling, why not write a real method? Get/Set couples you to your class fields. If you change your class fields, your getters and setters all suddenly become useless.
Maybe I just hate the middle ground (:
Re: Data Classes for Java
#107... 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…
> 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 think it's because you can't specify fields interfaces. If you different data classes, but you want them all to be "Named", you need "getName()" on your "Named" interface, because you can say that it should have a "name" field.
Of course, that's a language flaw, but it's one that people have to work around.
Re: Data Classes for Java
#108Earlier quoted context omitted.
But by definition getters and setters lack lexibility. They expose the internal representation of an object. They stop really being "objects" - high level opaque things you send messages to - and they turn into big porous bags of fields. To clarify, I would not consider something like this a setter: class Monster { int health; void Damage(int d) { this.health -= d; } } True, it is a method that just sets a variable.…
`Technically` The current representation of `objects` in java is a abomination to the original idea behind object's. Hell even the use of class, members and fields fly in the face of what real objects are.
Do physicists argue about the true nature of gravity because Newton had the "original idea" behind it?
Re: Data Classes for Java
#109... 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;" wil…
> if we make a change in future it's going to take just as much work
In Java, changing from a field to using accessor methods requires source changes on the consumer side as well as the class itself. With C# properties this is transparent in source, but I think it still requires recompilation on both sides. Not using fields, therefore, means changes have less impact on other compilation units that might consume the class.
Re: Data Classes for Java
#110Earlier quoted context omitted.
How about a class that stores temperature and the current state of the satellite? It's easy to come up with circumstances where requirements change.
Then I would implement it as a "real" class, not a data one. class Satellite { Coordinates coordinates; double celcius; /*** constructors, etc ***/ public double Celcius() { ... } public double Kelvins() { ... } public void Move(...) { /* modifies state */ } } Note how none of the methods make any mention of low level operations like setting/getting internal fields. You could make the argument that I do have a getter…
Celcius is definitely a getter. The name absolutely implies that it's retrieving a value because it's name is not a verb or action.
Properties in C#, for example, really just remove the ambiguity in this exact situation. Is it object.Celcius or object.Celcius()? A good C# programmer would use the former. A method would be object.RaiseTemp().