Property methods: just shoot me now

How much time I spend, writing crap like this:


class Something
{
private int id;
private String name;

public int getId() { return id; }
public void setId(int id) { this.id = id; }

public String getName() { return name; }
public setName(String name) { this.name = name; }
}

Any decent IDE will generate the property methods for you, but why is this necessary? Way back in ancient history, Visual Basic knew how to do the right thing: If you defined a setter for some property, then VB would call it when the application set the property. Set it how? With the equals operator, of course. (The equals operator was how software developers assigned values to variables prior to the release of the JavaBeans specification.) And if you defined a getter, then VB would call the getter when the app used the property in some non-lvalue context. If you didn't provide a getter or setter, then no problem, VB just treated the property as a regular old field.

In an anemic domain model, whole classes may exist with nothing but private fields and a public getter and setter for each. What's the point? Why not just make the fields public and be done with it?

Someone's going to say, well, we don't know what's going to happen in the future, and someday we might want to add actual business logic to one of those property methods. That seems like a great example of doing a lot of work now in order to avoid some potential work that may need to be done in the future, which is exactly what we shouldn't be doing. And anyway, if you really want a struct then you should just say so:



/**
* This class is a structure used to pass A from X to Y.
* All fields are public. Do not add logic.
*/
class Something
{
public int id;
public String name;
}

I think that my biggest gripe about the proliferation of property methods is that Java doesn't do anything to make it easier for us. Java forces us to decide, up front, whether we want to expose the field or "hide" it behind trivial methods, and then makes us actually write the trivial methods if we want them. VB got it right. Why can't Java?

Comments

Post a Comment

Popular posts from this blog

UUIDs as primary keys

I wrote in my last post that I preferred to let the database just store data and and implement all the business logic in my Java code but that I usually let the database handle primary key generation. After thinking about it for a few days, I decided to experiment with using UUIDs as primary keys. Java 5 has a convenient java.util.UUID class that I used to replace the integer identifiers in my entity classes. I found a bunch of blog entries about using UUID versus integer primary keys. UUIDs do have some disadvantages: UUIDs are larger than integer IDs. A UUID, when stored in its most compact form, consumes 128 bits, or 16 bytes. That's four times larger than a regular 32-bit integer. UUIDs are binary. While they fit in a 16-byte binary column, when expanded into a string, they typically consume 32 or 36 characters, depending on whether the string is the human-friendly 00112233-4455-6677-8899-aabbccddeeff format. UUIDs are computationally harder to generate than integers. The disad
Read more

Scala and Kotlin

I've been spending the last three years writing code in Scala. In general I've been pretty happy with the language. It's much more compact than Java, and its higher-level features, such as closures (which have been around forever but which were popularized, I think, by Ruby), enable me to discard several of the Java tools and frameworks that I've had to drag around. Scala also comes with a very powerful collection library that I use on just about every line of code. Lately I've been following Kotlin, which looks very promising. I'm old enough to realize that this may just be a case of the grass looking greener on the other side of the fence. Every programming language has its flaws, and Scala is no exception. There's always the sense that maybe the next language will be The One. The One that does everything perfectly. The One that incorporates all that is good about Java and Scala and C# and C and C++ ( well okay, maybe not C++ ), introduces exciti
Read more

Generating thumbnail images: AffineTransformOp gotchas

AffineTransformOp is a Java 2D filter that can scale (resize), rotate, and/or skew an image. Since I was generating thumbnails, I was only interested in its scaling ability. To scale an image using AffineTransformOp, all you need to do is generate a new AffineTransform using the static method AffineTransform.getScaleInstance, then use it to construct an AffineTransformOp. When constructing an AffineTransformOp, you also need to pass a constant theat identifies the type of interpolation to use, either nearest neighbor, bilinear, or bicubic. Once you have the AffineTransformOp, you just call the filter method, passing in the original image and the destination image, which can be null, in which case AffineTransformOp will create a destination image for you. After generating my first thumbnail image and saving it as a JPEG, I was able to view my generated thumbnail image in Preview, but it looked like crap. It looked blocky, as if AffineTransformOp was using the nearest neighbor interp
Read more