Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data Classes for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

61–70 of 216 posts

Re: Data Classes for Java

#61

Post by danvasquez29 »

HumanDrivenDev wrote: post #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 l…

I do it in PHP to make something immutable. data goes into the constructor and then only getters are provided.

Re: Data Classes for Java

#62

Post by kevingadd »

flukus wrote: post #32
bunderbunder wrote: post #16

Earlier quoted context omitted.

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.

> Possibly more importantly, public fields give you no way to create immutable types. public readonly int Foo; readonly fields can only be set in the constructor, great for immutable types and with much better guarantees than protected/private/no setters.

This isn't true. For structs you can use 'this = ...' to overwrite yourself (including readonly fields) and reflection lets you set them too.

fwiw those are both gross but I've run into both in production code (not written by me, naturally)

Re: Data Classes for Java

#63

Post by bobbyi_settv »

harryh wrote: post #3

I, for one, am enjoying the ever so slow scalaization of java.

But it also can be annoying as a Scala programmer because you are going to have to be aware of both the Java and the Scala versions of each thing and how they differ.

For example, under this proposal, you will need "new" when creating an instance of a Java data class, but you are probably in the habit of omitting it when creating an instance of a case class.

Re: Data Classes for Java

#64

Post by arthur_pryor »

HumanDrivenDev wrote: post #55
arthur_pryor wrote: post #41

Earlier quoted context omitted.

what if the constructor's not the only place you can set the value?

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, 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 classes written by their predecessors. in which case, setters can be nice.

or they can be annoying boiler plate. seems like a case by case thing to me. i think the getter/setter thing does often feel needlessly verbose, and so i upvoted your original parent comment. but "setters are always bad and i don't understand why anyone would ever use them" seems like a needlessly hard-line sentiment, IMO.

Re: Data Classes for Java

#65

Post by aomix »

HumanDrivenDev wrote: post #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 l…

These kind of classes are structs with busy work attached. At work I feel a little guilty when I delete them over the course of refactoring but if no processing on the incoming and outgoing data is necessary then public fields are better in every way by being easier and simpler.

Re: Data Classes for Java

#66

Post by geophile »

mikeash wrote: post #30
derefr wrote: post #10

Earlier quoted context omitted.

> 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/sette…

I like Swift's approach to this. (I'm sure other languages do it too, that's just the one I know that does this.) If you write a property (what other languages might call a "field") then by default it's a stored property, i.e. it's backed by a bit of memory in the object. If you need to take actions on changes, you can implement a willSet or didSet handler to do so. If you need to change how the value is stored and r…

I really, really dislike Swift's approach. get/set/willSet/didSet -- so much complication to preserve the illusion that you are operating on a field when you are actually doing no such thing. Why is this desirable? It reminds me of a class of C++ footguns where some innocuous code is actually invoking member functions due to operator overloading.

I think that Java got this one right. (I do not at all like the cargo cult custom of getter/setter methods for fields; I'm referring to the language only.)

Re: Data Classes for Java

#67

Post by hrktb »

chubot wrote: post #52
Tarean wrote: post #24

Earlier quoted context omitted.

If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…

FWIW, I've been writing software professionally for more than 15 years, and I've literally never come across this problem. It feels contrived to me. However, there are many different types of programming, so I'll concede it the technique could be useful in domains I'm not familiar with. But if there any such situations, then I don't think they explain the wide popularity of getters and setters. I rarely use getters a…

I think the popularity of getter and setters come from a mix of dozens of small problems to solve.

Protection from internal representation change is one. Expliciting what can be done with a property is another (i.e force write only or read only properties by only exposing a setter or a getter). Exposing “virtual” properties that are a combination of “real” properties (i.e. exposing a string representation of a price with a currency for instance, where both the price and currency are independant properties). Spying on getters and setters also helps for testing. And so many other potential uses.

Each use case is not a big deal on its own, but there is enough chance to hit at least one of the potential use case for at least some of the objects that autogenerating getter and setters for basically everything is seen as a good practice. Also no one gets fired for putting getter/setters, the reverse could be true.

I personally prefer contexts where I don’t have to care so much about all the above (this means less protective programming in general), but in a lot of enterprisey applications generating getter/setter everywhere is just a way of life.

Re: Data Classes for Java

#68

Post by xapata »

HumanDrivenDev wrote: post #60
goflyapig wrote: post #56

Earlier quoted context omitted.

This only works if your class is immutable. If a client sets either of those fields, they will now be out of sync.

Why have a mutable class to represent temperature - a simple value class with two fields? Why not just construct a new Temperature? I mean if performance was an issue, you'd just use plain doubles instead, right? I'm open to the idea that setters do have a use case, but I'm not seeing one here.

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.

Re: Data Classes for Java

#69

Post by jimmaswell »

guelo wrote: post #37
tantalor wrote: post #25

AutoValue with Builders is nice: Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); https://github.com/google/auto/blob/master/value/userguide/b...

Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.

Very similar in C#:

var dog = new Animal(){ name="dog", numberOfLegs=4 };

I use it all the time.

Re: Data Classes for Java

#70

Post by coredog64 »

chubot wrote: post #52
Tarean wrote: post #24

Earlier quoted context omitted.

If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…

FWIW, I've been writing software professionally for more than 15 years, and I've literally never come across this problem. It feels contrived to me. However, there are many different types of programming, so I'll concede it the technique could be useful in domains I'm not familiar with. But if there any such situations, then I don't think they explain the wide popularity of getters and setters. I rarely use getters a…

How about this non-contrived example:

Certain data types (Array, Java.util.Date) expose private information if you just blindly return your instance variable to the caller. Setting can be dumb, but you may want to create a defensive copy to hand back on get.

C# syntactic sugar makes that apparent to the reader.

Post reply on HN