JDK 7: Proposition 12 : déclaration des propriétés [Débat]

**vbrabant** · 18/12/2007, 22h44

But: supprimer le fait d'écrire des setters et getters

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public class Person {
 public property String forename;
 public property int age;
}

**JPDMJC** · 19/12/2007, 00h25

J'ai voté non, je préfère garder un plein contrôle sur mes getters et setters.
Certes, ce mot clef permettrait d'économiser quelques lignes de code, mais enfin bon, les éditeurs d'aujourd'hui peuvent les construire en un ou deux clics.

Sinon, pour le code exemple, l'appel du getter sous-entendu - par exemple pour la propriété age - serait bien getAge() ? C'est juste pour être sûr à 100%, des fois que ^^.

**metalpetsFR** · 19/12/2007, 09h33

Moi je suis 100% pour, je pense même que c'est la proposition la plus intéressante, pour plusieurs raison

1 De nombreux framework utilise la reflexivité (PropertyUtils#setProperty(..)) pour mettre a jour l'attribut d'un objet,
puis avec son IDE préféré en fait un "open call hierarchy" sur la méthode on trouve aucun appel.... dommage
2 Pour les commentaires on souhaite souvent décrire l'utilité d'un attribut et non pas la méthode pas la méthode qui va mettre ajour cette propriété. A moins de triplé le commentaire(attribut, setter getter)
3

je préfère garder un plein contrôle sur mes getters et setters.

Ici on parle de property, une property au sens java bean, n'a pas a avoir de controle.

Je crois que ceci a été faite dans C#, mais je n'ai jamais expérimenté.

Merci pour le débat tres intéressant... :p

**Uther** · 19/12/2007, 10h10

Pour, mais il faudra que ca soit plus avancé que cette courte description. Il faudrait garder la possibilité de redéfinir les getter/setters, et de faire des propriété read/write only.

J'ai vu pas mal de sujets intéressant qui discutaient de la manière de traiter ca.

**zulot** · 19/12/2007, 10h19

Pour si on peut garder la possibilité de faire des getteur setteur.

**austin P.** · 19/12/2007, 11h02

plutot pour

evite les kilometres de getter et setter
vas dans le sens de l'IOC qui est un plus
il manque par contre la notion de read/write

**jproto** · 21/12/2007, 15h26

Envoyé par zulot

Pour si on peut garder la possibilité de faire des getteur setteur.

Pour, tant que ce comportement ne s'applique que lorsqu'aucun getter/setter n'est défini. En fait, à la façon du constructeur par défaut implicitement généré par le compilateur lorsqu'aucun constructeur n'est défini pour une classe.

**Supersami2000** · 19/12/2007, 11h06

Pour mais un peu plus configurable.
Sinon comment dire "je veux juste un setteur" "le setteur est protected"

Pourquoi ne pas ajouter des annotations prisent en compte au javac

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class Person {
 @access readWrite protected
 public String forename;
 
 @access read public
 public int age;
}

**bgrand** · 15/01/2008, 11h30

Envoyé par Supersami2000

Pour mais un peu plus configurable.
Sinon comment dire "je veux juste un setteur" "le setteur est protected"

Pourquoi ne pas ajouter des annotations prisent en compte au javac

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class Person {
 @access readWrite protected
 public String forename;
 
 @access read public
 public int age;
}

Je vais dans le même sens que Sami, je suis pour à condition d'avoir une notion de permission. Les annotations me semblent tout à fait appropriées.

**adiGuba** · 15/01/2008, 11h34

Envoyé par bgrand

Les annotations me semblent tout à fait appropriées.

Sauf que les annotations n'ont aucun impact sur le code source généré, mais se contente d'ajouter des informations...

a++

**bgrand** · 15/01/2008, 11h46

Envoyé par adiGuba

Sauf que les annotations n'ont aucun impact sur le code source généré, mais se contente d'ajouter des informations...

a++

Informations qui sont prisent en compte par la JVM pour modifier le comportement du programme. Je ne suis pas spécialiste des annotations, je ne sais pas trop dans quelle mesure c'est possible de les utiliser dans ce cas là...

**adiGuba** · 15/01/2008, 11h53

Envoyé par bgrand

Je ne suis pas spécialiste des annotations, je ne sais pas trop dans quelle mesure c'est possible de les utiliser dans ce cas là...

Disons que dans les spécifications des annotations il est indiqué que les annotations ne peuvent pas modifier le code généré pour le fichier dans lequel elle se trouve.

Grosso modo les annotations peuvent être utilisé par le compilateur pour générer des warnings/erreurs mais pas pour générer un code différent...

Donc dans l'état actuel une annotation ne pourra pas générer le code des getter/setter (bien sûr les spec des annotations pourraient changer)

a++

**fbn69** · 15/10/2008, 11h45

Envoyé par Supersami2000

Pour mais un peu plus configurable.
Sinon comment dire "je veux juste un setteur" "le setteur est protected"

Pourquoi ne pas ajouter des annotations prisent en compte au javac

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class Person {
 @access readWrite protected
 public String forename;
 
 @access read public
 public int age;
}

Je suis favorable, par des annotations, du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public class Person {
 @withGetter
 @withSetter("private")
 public String name;
}

Intérêts :
- très lisible,
- moins de code,
- souplesse :
* possibilité d'écrire son getter/setter si on veut
* possibilité de modifier l'accessibilité private/public (par défaut c'est celle attribué à la propriété)

**TheNOHDirector** · 16/10/2008, 19h13

Envoyé par Supersami2000

Pour mais un peu plus configurable.
Sinon comment dire "je veux juste un setteur" "le setteur est protected"

Pourquoi ne pas ajouter des annotations prisent en compte au javac

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class Person {
 @access readWrite protected
 public String forename;
 
 @access read public
 public int age;
}

Je vote pour pour deux choses:

* La première, seulement dans le cas ou les accès aux propriétés par setters ou getter sont définis par des annotations et là je reprends l'idée de Supersami2000.

En revanche j'ai des interrogations sur les propriétés qui sont des collections. C'est du sucre syntaxique mais l'idée serait de pouvoir effectuer les opérations courantes sur les collections à travers des annotations spécifiques à ces collections et si nécéssaires spéciliasées pour telle ou telle collection (genre une map). De plus l'intérêt serait de ne pas récupérer directement la collection et de faire n'importe quelle opération dessus

En gras le code généré par le compilateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
class BusinessDataBean {

  @Access({"private read", "private write"})
  @ListOperations({"public addAll", "public add", "public removeAll", "public remove"})
  private List<String> strings;

  @Access({"public read"})
  @MapOperations({"public get" , "pubic containsKey", "private put" })
  private Map<String,Integer> translationMap;

  {
     putInTranslationMap("blahblah", 0); // ok ce put éxiste en privé.
  }
}

class BusinessHandler {

  public void doSomething(BusinessDataBean bean) {
    bean.setStrings(new ArrayList<String>()); // error : le setter est privé
    bean.addToStrings("blahblah");
    bean.removeAllInStrings(...);
    bean.addAllToStrings(...);
    
    bean.getTranslationMap(); // error : on ne pas avoir accès à l'instance de la collection
    bean.containsKeyInTranslationMap("blahblah");
    bean.putInTranslationMap("blahblah", 0); // error : le bean ne permet de put
  }
}

Evidement les collections seront automatiquement initialisée, et ces initilisations sont toujours configurables à l'instanciation de l'objet.

* La seconde raison est à propos de la documentation, très souvent ce sont les propriétés qui sont documentés dans les objets du domaine métier, et les accesseurs n'ont soit pas de commentaire ou le commentaire par défaut de l'IDE. Grâce à cette syntaxe un développeur qui veut consulter la documentation aura directement accès à celle de le propriété voulue, éventuellement l'ide pourra ajouter des informations pour dire qu'il s'agit de telle ou telle méthode : setter, getter, et dans le cas de ma propositions la javadoc de la collection.

Je trouve que cette idée prends tout son sens lorsqu'on modélise avec un outils UML, on ne s'amuse pas à documenter les getter et setter autres appels sur une collection.

Bref qu'en pensez vous!

EDIT : Après en avoir discuté avec des collègues, les property à partir du moment ou elles sont dans un javabean elles devrait être publiques. Un peu comme dans Groovy. Si on veut un comportement particulier pour tel ou tel accesseur d'une propriété alors on l'écrit pleinement.

Du coup on aurait soit le mot-clé property soit une annotation @Property. D'ailleur en soit l'utilisation du mot clé ne me dérange pas, on a bien du subir des changements marquant pour passer à java 5 notamment pour l'enum. Si on ne change rien pour garantir à tout prix la compatibilité ascendante on n'arrivera jamais à rien et se serait une usine à gaz.

**elitost** · 19/12/2007, 11h08

Je vote pour, même si ça pourrait être "confusing".

**romaintaz** · 19/12/2007, 11h28

Clairement pour !
C'est franchement lourd, inutile et polluant de mettre 50 getters et setters dans son bean Java.
D'autant que si j'ai vraiment besoin que mon getter (ou setter) fasse quelque chose de spécial, alors je définis moi-même mon getter ou setter.
L'idéal serait que si je fais ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public property String maPropriete;
 
public String getMaPropriete() {
    // mon code à moi
}

alors ce soit mon getMaPropriete() qui soit appelé, mais pour le setter, c'est Java qui gère...

**OButterlin** · 19/12/2007, 11h36

Pour, évidement, il faut pouvoir redéfinir le getter/setter si besoin est...
Donc, dans le cas suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class MonObjet
{
   private property String chaine1;
 
   public String getChaine1()
   {
      return chaine1 == null ? "" : chaine1;
   }
}

fonctionnerait comme l'override...
Quelle serait la convention utilisée pour les boolean ( isMaPropriete() ou getMaPropriete()...)

**heid** · 19/12/2007, 11h57

je préfère de loin la syntaxe c# qui me parait un très bon compromis entre fonctionnalité et concision :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
private String _test;
public String test
  {
    get
    {
      return _test;
    }
    set
    {
      _test = value;
    }
  }

**BakaOnigiri** · 19/12/2007, 12h02

pour, mais comme le dit OButterlin il faut pouvoir faire en sorte qu'un getter/setter perso prenne le pas sur le getter/setter automatique

**romaintaz** · 19/12/2007, 12h02

Pas vraiment d'accord avec heid, dans la mesure où la proposition du langage permettrait de zapper complètement l'écriture des getters et setters basiques. Là, tu es obligé de tout écrire, même si c'est un peu plus propre / court qu'actuellement...