Keith Lea: Java has had the concept of beans and getters and setters for a long time. I thought we had all agreed that they work and clearly show intent. I felt annoyed when I saw the java.util.regex package appear in Java 1.4 with methods like matcher(CharSequence) and group(int), when they should have started respectively with create and get. I didn’t like so much the new Java 5 util.concurrent methods Executors.callable(Runnable), which should be prefixed with get or create.
I know this sounds silly, but I can't convey how much dropping the get
seriously upsets me. I understand the bean convention came second (look at String.length() for example), but
(as opposed to
) now constitutes the vast majority of cases with good reason. The lack of consistency throws everything off. Method names should be verb phrases. In a world with ubiquitous auto-completion, prefixing method names names with get
helps users find methods; it doesn't result in extra typing. Dropping the get
actually causes more work for me because I always look for a getter first only to realize the author subscribed to this atrocious convention. I also can't say I've ever seen a case where a get
meant the difference between wrapping or not wrapping a line.
I've discovered many of the offending API designers spend most of their time in lower level Java libraries safely hidden from messy problems like automating UI design, handling HTTP requests, and mapping objects to relational databases and XML. The bean convention doesn't help them. They aren't aware that it enables frameworks which greatly simplify users' lives. Is it an ideal solution? No, but therein lies the nature of the domain.
Java's lack of syntactic support for properties does not justify these egregious hacks. We have a real problem, but we shouldn't try to contort method calls to look like property accesses; it doesn't work. Let's take a page out of the BeanShell book
and solve the problem by overloading field operators. Which do you think looks more readable?
Foo f = bar.foo();
Foo f = bar.foo;
bar.foo = f;
For the latter case, in the absence of a visible field
, the compiler generates:
Foo f = bar.getFoo();
Who exposes fields anyway? Nobody. Simple, eh? Some may scream, "operator overloading," but truthfully special cases like this are perfectly safe, backward compatible and in the Java spirit.