I really hate Java beans and their screenfuls of boiilerplate code. I had an idea to get rid of this that I’m calling Matrix Methods:
public class Bond {
private double price, yield, spread;
public {att} get{att}() {
return {att(price, yield, spread)};
}
public {att} get{att}Bps() {
return {att(price, yield, spread)} * 10000.0;
}
public {att} get{att}Percentage() {
return {att(price, yield, spread)} * 100.0;
}
}
Don’t use JavaBeans then. They are a travesty of OOP design.
Here’s a tip: if all you’re doing with properties is getting and setting them … use the dot operator. That’s what it’s for. Just remember that properties are often used in a way that is basically breaking the whole idea of OOP design (“encapsulation”).
Cas 
The idea is this is more generalized than just getters and setters, I’m only using them as a simplke example…
I’m a little confused- are you trying to propose a feature that should be added to the language itself?
If beans really bother you, you might consider taking a page out of the Calendar class’s book:
import java.util.HashMap;
import java.util.Map;
public class Bond {
public static enum BondField{
price, yield, spread;
}
private Map<BondField, Double> fieldMap = new HashMap<BondField, Double>();
{
fieldMap.put(BondField.price, 0.0);
fieldMap.put(BondField.yield, 0.0);
fieldMap.put(BondField.spread, 0.0);
}
public double get(BondField field) {
return fieldMap.get(field);
}
public void set(BondField field, double d){
fieldMap.put(field, d);
}
public double getBps(BondField field) {
return fieldMap.get(field) * 10000.0;
}
public double getPercentage(BondField field) {
return fieldMap.get(field) * 100.0;
}
}
Or you could convert the class into an immutable class, then add methods that return modified versions of the class, along with static helper methods for converting the fields to the information your want:
public class Bond {
public final double price;
public final double yield;
public final double spread;
public Bond(double price, double yield, double spread){
this.price = price;
this.yield = yield;
this.spread = spread;
}
public Bond withPrice(double price){
return new Bond(price, this.yield, this.spread);
}
public Bond withYield(double yield){
return new Bond(this.price, yield, this.spread);
}
public Bond withSpread(double price){
return new Bond(this.price, this.yield, spread);
}
public static double bpsOf(double d) {
return d * 10000.0;
}
public static double percentageOf(double d) {
return d * 100.0;
}
}
So there are other approaches, but simply using a bean is probably better for readability and maintainability.
Have a look at lombok. I think lombok introduces some nice code sugar. Auto generated getters and setters are part of lombok if I remember correctly.
Or better yet, since you’re not writing a long lifetime public API used by thousands that are hampered by API changes…don’t use getter/settters.
I always start with an empty class definition, and add functions as they’re needed. I think it’s bad form for code to contain stuff that’s never used - aside from the obvious code bloat it can be confusing because it suggests there might reasonable use cases when there aren’t.
I was thinking about this for my work, not strictly for gaming. It seems to me to be a neat way to write code once - don’t repeat code, write metacode instead.
@richierich: it would still be possible for an IDE to warn if variations of the metamethod are not used.
If this was a Java language feature, I would definitely use it.
For this to be usable, you’d have to have the ability to include or uninclude particular attributes, which would probably mean annotations.
And at that point, why not just use lombok? It’s actually less verbose than your solution.
I say again… Beans are a giant facepalm. Don’t use them, or their idioms. View “properties” as you would an embarrassing disease of the genitals: best tell as few people about it as possible.
Cas
Well, using Beans and their idioms depend on the context. If you work in any kind of Enterprise Java job, there is simply no way to avoid them…
Ah, but that is a hell especially reserved for the mediocre :persecutioncomplex:
Cas
so it’s official, I’m mediocre 
The mediocre, and people who want to be employable in 5 years… 
There are other jobs besides making little boxes for drones to send numbers into databases…
Cas
By “enterprise” I assumed we meant JavaEE or more generally, server-side Java. That’s where all the (Java) jobs are going- ain’t nobody hiring front-end Java developers anymore. Those jobs are all going to javascript kids.
Sure, we can still hobby away at game development or Android development, and a lucky minority of us can make money that way. But for most Java developers, we either have to learn JavaEE (and accept that it uses beans all over the place), or learn javascript.
If by “enterprise” we meant something else, then I take back my statement. But there’s plenty more to server-side Java than little boxes and databases.
I’d take my chances with C++ rather than get into enterprise Java. :
Fair enough. I’ve been dabbling in JavaEE and Spring for a little while now, and I actually like it a lot more than I thought I would.
Now if only I could make anything I do look pretty…
(I guess I have the same problem in game development, heh)
Still quite a lot of front-end Java work around as far as I can see, though not as much.
Cas
My day job is a Swing (and now GWT) developer. But whenever I peruse job offerings, most of them are for Spring or JavaEE.
I would love to work as a Swing (or JavaFX) developer the rest of my life, but I don’t see that happening.