Discussion :

[vbrabant]

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]

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]

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]

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]

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

[austin P.]

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

[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;
}

[elitost]

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

[romaintaz]

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]

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]

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]

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]

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...

[bassim]

Je suis pour si toutes les propositions précédentes sont présentes

[eclesia]

Contre. Imaginer que vous vouliez changer le nom de votre variable. le nom des get/set changera avec ... quel beau bordel ca fera.

[heid]

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...

Justement zapper complètemen je suis contre. et les get set c'est trop lourd syntaxiqueemnt.

[romaintaz]

Je reste pour
La plupart de mes accesseurs sont vraiment basiques, je préférerais placer le mot property devant, et c'est marre !
Vu que c'est un ajout à l'existent, rien ne m'empêche de garder mes bons vieux setters et getters si j'en ai envie !
C'est comme le for (String maString: maListeDeString) { ... } : ça n'ajoute pas de nouvelles fonctionnalités, mais ça allège le code de lignes inutiles...

[bulbo]

Un tout petit petit pour ..

D'ailleurs ça doit être faisable déjà aujourd'hui avec des assertions.

Pas un gain énorme sauf quand on doit écrire un javabean stupide a la mano, mais la plupart du temps on passe par un framework X ou Y aujourd'hui donc ..

Faudrait que la javadoc suive aussi dans ce cas et ajoute les méthodes invisibles dans le code automatiquement.
Pour moi inutile de donner la priorité a un getter écrit a la mano par exemple, il faut dans ce cas virer le mot clé property et faire les choses correctement en contrôlant le getter et le setter.

Bulbo

[romaintaz]

Pour moi inutile de donner la priorité a un getter écrit a la mano par exemple, il faut dans ce cas virer le mot clé property et faire les choses correctement en contrôlant le getter et le setter.

Je suis tout à fait d'accord, c'est bien plus propre. Maintenant, rien ne t'empêche de définir un setter (ou un getter) sur une property, et dans ce cas, j'estime qu'il est important que le setter (getter) défini manuellement soit prioritaire...

[bulbo]

Je suis tout à fait d'accord, c'est bien plus propre. Maintenant, rien ne t'empêche de définir un setter (ou un getter) sur une property, et dans ce cas, j'estime qu'il est important que le setter (getter) défini manuellement soit prioritaire...

Tu peux aussi avoir une erreur de compil qui te dit que tu essayes de redéfinir un get/set d'une property et je préfèrerais ça. Imagine tu fais une faute de frappe dans le nom de ta méthode .. du coup tu n'appelleras pas la bonne et en regardant ton code tu auras l'impression que si ..

Alors que si 'property' get/set auto sinon get/set a la mano, tu es sur de pas te planter..

Bulbo