Un nom de propriété booléenne préfixé par "is" est-il toujours un Java Bean valide ?

Question

Je viens de remarquer quelque chose que je ne savais pas.

  private boolean isCertified;

  public boolean isCertified() {
    return isCertified;
  }

  public void setCertified(boolean certified) {
    isCertified = certified;
  }

Les getters et setters suivants ont été générés par Intellij. A propos, Lombok génère le même type de getters et setters.

Je me serais attendu à quelque chose comme :

  private boolean isCertified;

  public boolean isIsCertified() {
    return isCertified;
  }

  public void setIsCertified(boolean certified) {
    isCertified = certified;
  }

C'est pourquoi je n'ai pas l'habitude de faire précéder mes attributs booléens de la mention ìs Malgré cela, je pense que le nom de la propriété est plus lisible.

Normalement, j'écris quelque chose comme :

  private boolean certified;

  public boolean isCertified() {
    return certified;
  }

  public void setCertified(boolean certified) {
    certified = certified;
  }

---

Alors je me demande :

• Avoir une propriété nommée isXXX et un getter étant isXXX au lieu de isIsXXX : s'agit-il d'une définition valide de Java Bean ?

• Existe-t-il d'autres cas de figure cachés de Java Bean comme celui-ci, que je pourrais vouloir connaître pour améliorer la lisibilité du code ?

Gracias

Answer 1

À ma connaissance, le modèle de dénomination des champs ne fait pas partie de la spécification JavaBeans.

La spécification JavaBeans spécifie (entre autres) le concept de "propriétés".

Les propriétés d'une classe sont identifiées par les méthodes (nommées d'après un certain modèle) d'une classe.

Les champs ne sont pas pertinents. En fait, il n'est même pas nécessaire qu'il y ait un champ pour une propriété.

Cela dit, il est toujours préférable de nommer les champs d'après les noms des propriétés. Il y a plus de chances que les outils qui doivent également accéder aux champs (par exemple, le support du refactoring dans les IDE) traitent les champs correctement.

Avoir une propriété nommée isXXX et un getter étant isXXX au lieu de isIsXXX : est-ce une définition valide de Java Bean ?

Non, un getter pour une propriété isXXX nécessite isIsXXX() (pour les booléens) ou getIsXXX() .

Mais là encore, c'est l'inverse.

Si vous avez une méthode :

boolean isXyz()

alors vous avez une propriété lisible xyz .

Si vous avez une méthode

boolean isIsXyz()

alors vous avez une propriété lisible isXyz .

Pour plus d'informations, consultez le site Introspecteur la classe tutoriel ou la spécification JavaBeans :

http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138795.html

Answer 2

private boolean certified;

public boolean isCertified() {
    return certified;
}

public void setCertified(boolean certified) {
    this.certified = certified;
}

C'est bon. Pour plus d'informations sur les noms de variables, vous pouvez consulter oracle.docs

Answer 3

Le nom de vos champs privés n'a pas vraiment d'importance ; c'est pourquoi vos setters et getters sont là.

Answer 4

Étant donné que les propriétés des Java Beans sont généralement définies par leurs méthodes getter et setter (et que la variable membre réelle, très probablement privée, est ignorée à cette fin), oui, c'est parfaitement correct. Bien que j'appellerais toujours le membre booléen simplement certified mais c'est une question de style et de goût.

Answer 5

Lorsque vous générez des setters/getters pour une variable booléenne à partir d'un IDE (Eclipse dans la plupart des cas), c'est la manière standard dont les setters et getters sont créés. Il s'agit d'une définition parfaitement valide d'un haricot Java. En fait, lorsque vous utilisez des frameworks comme JSF où les valeurs sont transmises à l'aide de setters/getters, la définition de la variable booléenne et l'utilisation du setter/gettter généré deviennent en quelque sorte obligatoires.