tags:

views:

620

answers:

7

If a class contains a variable named "blah", then the standard getter/setter syntax is obviously getBlah() and setBlah(). But if I have a POJO class with a variable named isBlah, would I use:

public type getIsBlah() {
  return isBlah;
}

public setIsBlah(type isBlah) {
  this.isBlah = isBlah;
}

Or would it be this?

public type isBlah() {
  return isBlah;
}

public setBlah(type blah) {
  this.isBlah = blah;
}

The first seems to conform more strictly to the POJO conventions, but the second type is what IntelliJ generates if I ask it to make a class' getter/setters (and hey, IntelliJ has never let me down yet :] ). So which is the preferred syntax?

+1  A: 

Wouldn't say there's a strong convention for POJOs, but for JavaBeans the second (IntelliJ) example is the standard for boolean attributes, everything else uses getX.

Nick Holt
+1  A: 

I would also choose your second option. The first, with getIsBlah() seems wordy and redundant.

Greg Hewgill
+7  A: 

One reason for using properties is to decouple the API from the implementation. In other words, you shouldn't feel bound by what your private variable is called. That shouldn't inform the naming beyond trying to keep it readable to code maintainers.

I would say that if "type" is boolean in this case, then the second form is correct. If it's not boolean, you should use getXXX - but I probably wouldn't use getIsXXX. To me, "is" has a very strong correspondence with Boolean properties, and using it in other contexts would not only break the JavaBeans conventions (which could affect other tools) but would be misleading IMO.

Jon Skeet
+1 for breaking JavaBeans conventions
Vincent Robert
@Vincent: I assume you mean "+1 for mentioning that it would break JavaBeans conventions" - rather than "+1 - be a convention-breaker!" :)
Jon Skeet
+1  A: 

Both the "get" and the "is" is fine actually, as they are technically still acceptable under the JavaBeans convention. I'd go for whichever sounds better or more natural, depending on what word your "Blah" actually is.

aberrant80
+1  A: 

There's one big problem with the "is" syntax if you use JSTL, which is that JSTL EL doesn't recognise them. It's pretty stupid, but the designers of the JSTL EL didn't bother to check their logic for javabeans compliance.

I often find myself writing getIsBlah() methods in my view-layer classes, which call isBlah(), just to give JSTL a hook. It's horrible.

skaffman
Does this problem still persist with the latest JSTL?
Adeel Ansari
I believe so, although it's more a problem with the JSP EL than JSTL itself.
skaffman
I am pretty sure that isn't the case anymore.
harmanjd
+3  A: 

Note that the name of the field is completely irrelevant to the JavaBean specification. Only the names of the getter/setter are relevant.

Normally the name of the getter is get<PropertyName>(). Only for boolean properties is is<PropertyName>() allowed as an alternative.

Note that in your example the Bean property name is "Blah" when you call the getter isBlah() and it's "IsBlah" when you call your getter getIsBlah().

Personally I usually prefer isBlah().

Joachim Sauer
A: 

JSTL only allows isMyBool if it is a boolean, not a Boolean or any other object, as per the bean spec. (primitive vs object).

thetoolman