Question

The JavaBeans methods’ signature’s has to follow certain conventions such as set…/get… and such. They have a convention for is…for instance isEven() could be a method for an Integer class to test a boolean. But then I wonder why not has… is also a legal identifier since it makes sense to me to test what something has e.g. hasCar() for a Person class or likewise.

Do you understand my question? What do you think?

Answer 1

Well, the general convention is to use get... and set... and thus is... is just an exception for booleans. For is... the convention is easy: you need to return a boolean, can skip the getter and the corresponding setter will take a boolean parameter as well.

A convention for has... would be more difficult: has... would return a boolean but you’d still need a getter and setter which deal with different types. Thus has... is no replacement for get... as opposed to is... and since that part of the JavaBeans convention normally only is about getters and setters has... doesn’t fit in there.

From the JavaBeans spec:

Properties are discrete, named attributes of a Java Bean…

Properties show up in a number of ways:

1. …
2. Properties can be accessed programmatically by other components calling their getter
   and setter methods (see Section 7.1 below).
3. …

Any property being accessed using has... would not be persistent nor be accessed by its getter method.

Example: if a person has a car property, you’d expect to have a getCar() accessor. hasCar() wouldn’t be an accessor since the derived property hasCar would need an accessor named getHasCar() or isHasCar(). If has was an accessor prefix, the property would have the conflicting name car.