JavaBeans naming convenctions recap

[Daniele Barell]

Hi ranchers!
At Sybex book on OCA by Jeanne and Scott at page 206 there's a JavaBeans naming convenctions rules sum up.
They seemed easy and clear to me.
But when I got the relative review question ( n. 9 ) on these convenctions I miserably failed.
So I wanted to make a recap of these rules like I understood it. And make some questions

- Instance variables must be private. But static ones?
- Getters: if the property is a boolean must begins with is OR get. ie: public boolean isHappy(){return happy;} OR public boolean getHappy(){return happy;}. Can you give me a confirmation about boolean getters?
if the getter is another about java type it must begins with get only.
- Setter methods begins with set. ok

The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
but names that shorten the original one one are valid as well?
getNumOfExams() and setNumOfExams; are also valid for JavaBean naming convenctions?

Hope you'll make me clear.  

[Paul Clapham]

JavaBean naming conventions are in Wikipedia, here: https://en.wikipedia.org/wiki/JavaBeans#JavaBean_conventions.

By the way, static variables are irrelevant to JavaBeans. A JavaBean is an object which can be passed around to various users and it has various properties, which clearly can't be static.

[salvin francis]

Paul Clapham wrote:JavaBean naming conventions are in Wikipedia, here: ...

I think the correct link is https://en.wikipedia.org/wiki/JavaBeans#JavaBean_conventions

[salvin francis]

Btw, you have raised a good point about booleans. While typically, I would recommend to use "set" for setter and "is" for getter. There are situations where "is" does not sound grammatically correct e.g.

class Tiger{
    boolean vegetarian;
    boolean hasClaws;
    boolean canBite;
    boolean highJumper;
}

You could consider "has", "can", "contains" etc..
I hope my post does not raise a lot of eyebrows

[Paul Clapham]

salvin francis wrote:You could consider "has", "can", "contains" etc..
I hope my post does not raise a lot of eyebrows

You could do that... but there are products like JSTL which just expect the name of the property (e.g. "vegetarian") and under the covers look for methods named "isVegetarian" or "getVegetarian" to access those properties. However your examples show that the JavaBeans conventions don't always work nicely with boolean properties.

[Piet Souris]

Daniele Barell wrote:Hi ranchers!
(...)

hi Daniele!

Daniele Barell wrote:
The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
(...)
Hope you'll make me clear.  

No, it is the other way round!
Suppose you have this class:

public class Daniele {
    private String firstName, lastName;
    // constructor .....
    public String getFamilyName {return lastName;}
}

then you have the property: familyName, and its value is: lastName. You may be forgiven to think tht the property is lastName, to be retreived by the getFamilyName method, but as said, it is just the other way around.

[Paul Clapham]

And don't get hung up on the idea that the property is always represented by a private variable of the class. That's often the case, but not always. Consider this (trivial) example:

public class Universe {
  public int getAnswer() { return 42; }
}

(In real life there are obviously more realistic examples.)

[Paul Anilprem]

Piet Souris wrote:
hi Daniele!

Daniele Barell wrote:
The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
(...)
Hope you'll make me clear.  

No, it is the other way round!
Suppose you have this class:

public class Daniele {
    private String firstName, lastName;
    // constructor .....
    public String getFamilyName {return lastName;}
}

then you have the property: familyName, and its value is: lastName. You may be forgiven to think tht the property is lastName, to be retreived by the getFamilyName method, but as said, it is just the other way around.

True. In other words, a "property" of a class may not always have something to do with an instance variable of the class.  If you have a String getSalutation() method in a class, then that class has a saluation property of type String. Whether this method returns the value of an instance variable or fetches it directly from the database is irrelevant. If you also have a setSalutation(String ) in the class, then the property is editable otherwise it is just readable.

Similarly, if you have a isCertified or getCertified method that returns a boolean then the class has a boolean property named certified.