Java Beans: Overglorified Associative Arrays?

Question

I don't understand the nature of Java Beans that well. Well, at least how I see them used in some code-bases that pass through our shop.

I found this question:

Java Beans: What am I missing?

The accepted answer there makes it look like programmers tend to abuse Java Bean (which I really don't doubt), but I see it happen so often and so deliberately, I think I'm still missing something.

I see code that looks like:

public class FooBean {
  private int a;
  private int b;
  private int c;

  public int getA() { return a; }
  public int setA(int x) { a = x; }

  // etc...
}

No further structure or control than getters and setters. Is there some sort of super awesome compiler trick going on that involves reflection, getters and setters, and the need for some very awkward (but compiler optimized) static associative arrays?

Or maybe I'm completely missing the point. :\

Cheers!

Edit:

Definitely not promoting the idea of public fields, here.

Answer 1

Actually, yes, there is magic going on.

It's a really dumb pattern, but GUI beans (which all components are) were intended to be reflectively analyzed by a GUI builder. The public set/get fields are intended to be "Properties" that the user can muck with while building his GUI.

Edit: In defense of sun, I should say that although the pattern turned out to be pretty obnoxious because of all the people that copied it and started using it throughout their non-bean code, It did allow people to integrate classes with a GUI builder without using any outside meta-data. You didn't need any XML file or properties file for the editor, it was as easy as extending Button and dropping your new object onto the pallet.

This pattern has been used in other places and, as you noticed, it's pretty much the same as having public fields. I think it's one of the worst patters sun created when setting up java, but there were no other obvious solutions (I think the whole concept was kind of tacked on by the first people trying to build the first GUI builders before java's release).

Now there is a much better solution: using annotations to mark private fields, a reflective tool could still analyze them and bind them to the builder controls. This would be a good deal cleaner and not make all your objects so vulnerable to external state changes.

Answer 2

Java Beans are, as you point out, a fairly trivial coding convention.

The useful part is that they were a convention at all. This allowed auxiliary tools to be built which were based on (at the time) novel ideas like specifying exactly what the name of getters and setters were, and an expectation that specific methods would exist without needing to ascribe to an Interface. This allowed enough flexibility to do whatever you wanted, but still allowed you to use the GUI for assembling beans.

At this point, with full introspection being the norm, and other languages having formalized get/set functionality, and many other ways to do what Beans do, I think they're an idea whose time has passed.

Answer 3

People do overuse silly getter/setters, no doubt about that.

However, imagine how much pain you have to go through 2 years down the road when you realize you have to strip withespaces off the string in your setEmail(string email); method and all your code is hard coupled to use public fields instead of a method call.

Remember one of the major rules of object oriented design "Code towards an interface, not an implementation". Accessing public fields of a class is certainly the latter, and will make refactoring code much harder.

Answer 4

You're not missing the point. Getters/Setters are ugly, but are embedded into so many tools that make assumptions about class/method/field names (e.g. spring) that (aside from their obvious value for encapsulation) they've effectively become a near requirement, unless you're working in a very limited and private context.