4 ms·
Manually writing getters and setters is also pretty boring, in my experience.
by favorited 2y ago
Manually writing getters and setters is also pretty boring, in my experience.
- vips7L 2y agoThat's purely your choice on the libraries you use. Nothing in the language is forcing you to do this. Getter/setters are just a requirement of JPA which you don't have to use. In fact if you just use jOOQ or query dsl you can map to Java records.
- favorited 2y agoThe language isn't forcing it, but idiomatic Java (and decades of Java-based university training) is. Pretty much every professional Java project I've ever seen is full of code like: private Map<String, Client> clients; public Map<String, Client> getClients() { return clients; } public void setClients(Map<String, Client> clients) { this.clients = clients; } Kotlin's approach, where you declare and instantiate a property, and the getter/setter/backing storage are synthesized for you, is vastly preferable to me: public var clients = emptyMap<String, Client>()
- vips7L 2y agoI just disagree. This is not idiomatic Java; it's idiomatic JPA. All of the Java I see professionally and in the community uses immutable classes when not dealing with JPA entities.
- favorited 2y agoI guess you live in a more modern workspace than I do. I just picked an open source project that (A) I know we use at work, and (B) I know is written in Java. I picked a random source file that sounded like it would have some mutable state, and the very first functions below the constructor were a trivial getter and setter around a private ivar. https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/parser/QueryParser.java#L39 https://github.com/apache/solr/blob/main/solr/core/src/java/... I'm a little surprised it was in literally the first place I looked, but I'm not surprised that it was easy to find. "Use private ivars and write getters and setters to encapsulate your state" was probably the second thing that a generation of CompSci students learned in their first programming class, right after "an object is an instance of a class."
- vips7L 2y agoYou picked a project that (A) is literally older than the sun, (B) targets Java 11, a version from 5 years ago, and (C) the file is generated. Right at the top of the file... > /* QueryParser.java / / Generated By:JavaCC: Do not edit this line. QueryParser.java */ I'm not claiming you're not going to see properties written out. I'm just saying that's not the majority of code you're going to see and to claim that idiomatic Java is all getters and setters is a bit far fetched. Here is what I would consider modern idiomatic Java, immutable records and immutable classes that may expose some of their state: https://github.com/jstachio/jstachio/blob/main/compiler/apt/src/main/java/io/jstach/apt/Section.java https://github.com/jstachio/jstachio/blob/main/compiler/apt/... https://github.com/jstachio/jstachio/blob/main/compiler/apt/src/main/java/io/jstach/apt/NamedReader.java https://github.com/jstachio/jstachio/blob/main/compiler/apt/...
- kaba0 2y agoKotlin’s approach was a necessity to interact with a Java convention. Java instead tries to move away from that mutable convention to an immutable-preferring one with clearer rules (e.g. what is the correct setter and getter for an `IP` field?).
- DarkNova6 2y agoYou would be a fool to do exactly that. Use Lombok, or even better: immutable records. Setters are needed in exceedingly rarely circumstances.
- bradboimler 2y agoCan your IDE write them for you?