Comments on: A message to Sun engineers: Please stop making my code ugly

by: Bob Lee

Sat, 29 Oct 2005 14:21:18 +0000

Good words, Keith. Let’s nip this in the bud: http://crazybob.org/2005/10/i-heart-getters-and-setters.html

by: Dan

Fri, 02 Sep 2005 06:29:33 +0000

> Daniel Hinojosa:
>Hahaha! I agree. You donâ€™t know the squirming I have to do when I get asked, â€œIf >encapsulation is so important, why can you access length directly from any array? >and why doesnâ€™t it come with a getter and setterâ€?. :)

Dont squirm just explain Arrays are stupid objects with no behaviour - just data.

by: Keith

Wed, 31 Aug 2005 15:16:46 +0000

Rob, it should be called createMatcher if it creates a matcher. I never said anything about an “execute method.” The method is Executors.callable(Runnable) which simply creates a Callable instance which calls the Runnable and returns null, it doesn’t execute anything.

by: Rob Sanheim

Wed, 31 Aug 2005 15:11:40 +0000

Typically you only want getters and setters to be very simple operations that do not change the object state beyond the attribute in question. I think that is the reason things like the Pattern#matcher method is named as it is - the java doc says: “Creates a matcher that will match the given input against this pattern.” You really don’t want something that takes a param and creates a new object to be called “getMatcher”. Also, the execute method should definitely not be a getter or setter: “Executes the given command at some time in the future. The command may execute in a new thread, in a pooled thread, or in the calling thread, at the discretion of the Executor implementation.” This is definitely not a case where you want something to be called setRunnable, as it is really doing a whole lot more work then just setting an attribute.

So following the JavaBean naming convetion makes sense on simple pojos, particularily ones that face your GUI, but methods that do then get/set more work should not follow the standard just to allow tools to work.

by: Keith

Wed, 31 Aug 2005 14:32:39 +0000

In response to comment #4, if they are operations, why are their method names nouns? Operations are expressed using verbs in English.

by: Behrang

Wed, 31 Aug 2005 09:15:06 +0000

Sumit,

The problem is that “iterator” and “next” are not “properties”. The is/get/set convention is only applicable to properties. Nevertheless, I also don’t like seeing that built-in Java classes do not adhere to the naming conventions here and there. The first one I encountered was the Color.red, Color.green, … static variables which had to be Color.RED (Sun fixed this in 1.4) Also the classes/interfaces in the CORBA related packages are entirely against the conventions :-)

by: Anonymous

Wed, 31 Aug 2005 06:08:35 +0000

actually I believe in many (but not all) methods like that are operations in the strict sense and not properties which means they don’t really have to follow the java beans standards.

also with BeanInfo classes - equally part of the spec - you don’t have to use getX/setX for some property X anyway.

by: Charlie Hayes

Wed, 31 Aug 2005 01:12:26 +0000

I agree. It feels dirty setting public variables from outside a class. It doesn’t feel quite as dirty to read them, although still somewhat dirty.

by: Daniel Hinojosa

Tue, 30 Aug 2005 21:40:14 +0000

Hahaha! I agree. You don’t know the squirming I have to do when I get asked, “If encapsulation is so important, why can you access length directly from any array? and why doesn’t it come with a getter and setter”. :)

by: Sumit

Tue, 30 Aug 2005 21:03:11 +0000

Josh Bloch also suggests in ‘Effective Java’ that in general following conventions like JavaBeans is a good idea, but in some general-use APIs which are expected to get heavy use, it’s not a bad idea to make method names smaller. A typical case is teh Collections classes, which have methods like iterator() and next() rather than getIterator() and getNext(). After all, most likely somebody is typing these, and it’s no fun writing long method names always.

Sumit.