Discussion :

[Furikawari]

Est-ce que ça apporte une fonctionnalité nouvelle ? non.

Source de bug des getters et des Setters ?

Code peu lisible ?

Qu'on me dise "java aurait pu être conçu de sorte à avoir ça" je veux bien, mais tes arguments ne sont pas convaincants...

[Uther]

Est-ce que ça apporte une fonctionnalité nouvelle ? non.

Est ce que les generics apportent de nouvelle fonctionnalités? Pas vraiment c'est juste du sucre syntaxique, pourtant ça m'ennuie énormément de ne pas les avoir quand je travaille sur un projet limité en version 1.4.

Source de bug des getters et des Setters ?

Le principe même du getter/setter, n'est pas buggé.
Mais la duplication de code inutile augmente toujours le risque d'erreurs de programmation.
Par exemple, ça m'est arrivé d'avoir une faute de frappe qui fait que getter et setter ont un nom différent, ou une erreur de copier/coller où l'on a oublié de modifier le nom de la variable stockant la propriété.

Code peu lisible ?

Le code de certaines de mes classes est constitué à plus de 80% des setter/getters triviaux. Pour moi c'est clairement un gros défaut de lisibilité : une classe qui ne fait rien de particulier de devrait pas atteindre des centaines de lignes. Le code vraiment utile deviens nettement moins évident.
De plus comme on ne sait pas si un getter fait juste une affectation ou d'avantage, il faut prendre le temps de le vérifier si on veut éviter les mauvaises surprises.
Un des gros défaut de JAVA est qu'il est bien trop verbeux, et pour moi cette proposition d'évol, va dans le sens de corriger ça. C'est également le cas des closures.

Qu'on me dise "java aurait pu être conçu de sorte à avoir ça" je veux bien, mais tes arguments ne sont pas convaincants...

Oui et Java aurait également du être conçu de la sorte à avoir les génériques, heureusement qu'ils ont étés rajoutés par la suite.
Et puis ce ne serait jamais qu'un ajout pas un changement. Si ça plait pas, rien n'obligerait de l'utiliser.

[Furikawari]

Tes arguments se basent sur 1) je génère mes getters/setters à la main (source de bug) 2) ça représente 90% de mon code dans certain cas (masquage).

Comme plusieurs l'ont déjà fait remarqué : vive les EDI.

Maintenant, si java avait uniquement des problèmes de cosmétique, ça ne me dérangerait pas de voir ce point en tête de liste. Malheureusement ce n'est pas le cas, et je pense qu'il y a des choses bien plus importantes que de changer la syntaxe juste pour changer la syntaxe.

[Uther]

1) Ces problèmes je les ai eu bien que j'utilise des EDI.
2) je ne connais pas d'EDI qui masque les getter/setter automatiquement de manière élégante
Et même si les EDI étaient une solution miracle à tous les problèmes, les propriétés étant un concept de base JAVA, il me parait naturel qu'elles soient gérées au niveau du langage.

Quant au fait que JAVA ait d'autre problèmes à résoudre, je ne pense pas que ça entre en ligne de compte. Java n'est pas un petit projet amateur. Il y a largement assez de monde a travailler sur JAVA pour s'occuper de divers problèmes à la fois.

[Furikawari]

Dans le monde réel les ressources ne sont pas infinies...

[fbn69]

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é)

[lex2004]

Pour! Mais il faudrait y associer une syntaxe plus riche que le simple mot clé property. N'oublions pas que toutes les propriétés ne mappent pas forcément des champs (certaines retournent le résultat de traitements complexes)

[TheNOHDirector]

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.