JDK 7: Proposition 12 : déclaration des propriétés

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

Code:

---

1 2 3 4 5

public class Person { public property String forename; public property int age; }

---

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

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

Citation:

---

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

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.

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

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

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:

---

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, même si ça pourrait être "confusing".

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:

---

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

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

Code:

---

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

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

Code:

---

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

---

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

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

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

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

Citation:

---

Envoyé par 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...

---

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

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

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

Citation:

---

Envoyé par bulbo

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

Citation:

---

Envoyé par romaintaz

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

Il semblerait que toutes ces propositions aient un point commun... que le programmeur en code un minimum, quitte à rendre le code plus incompréhensible par des "opérations automatiques"
Je finirais presque par être contre toutes les propositions... sauf peut-être le switch String... et là, il faudra qu'on m'explique comment rendre indépendant le test d'un charset... (en le fixant peut-être ?)

Citation:

---

Envoyé par bulbo

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

---

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

Citation:

---

Il semblerait que toutes ces propositions aient un point commun... que le programmeur en code un minimum, quitte à rendre le code plus incompréhensible par des "opérations automatiques"

---

moi aussi, je trouve qu'il n y a vraiment rien de révolutionnaire dans ces propositions (pas comme les Generics dans java 5)

Citation:

---

Envoyé par romaintaz

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

---

Une petite annotation avec le nom du champ que tu redéfinis non?

Citation:

---

Envoyé par romaintaz

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien dans ce cas !

---

Si tu sais que property = set/get automatique tu ne vas pas chercher une méthode dans ton code qui fait ça, contrairement au cas ou ce serait possible.

Si tu te plantes de nom pour un setter définis a la main tu as deux cas ensuite:

- tu appelles toujours avec la bonne ortho -> tu utilises bien la property
- tu appelles avec le mauvais nom aussi (la tu cherches les problèmes :P) et un IDE classique te redirigeras sur la méthode appellée

Dans tout les cas je suis pas un grand grand fan de ce truc quel que soit son implémentation, surtout qu'un coup d'annotation et tu peux déjà écrire dans ton code aujourd'hui:

Code:

---

1 2	@bean_property private String name

---

et générer avec l'annotation le code qui va bien pour faire ce que tu veux.

Bulbo ;)

Je n'ai rien contre l'annotation, du moment que je n'ai pas à écrire (ou générer) mes getters et setters.
Mais alors autant la mettre directement dans le langage Java plutôt que d'utiliser des librairies externes...

Un petit contre... après une longue hésitation...

En fait le problème vient de l'existant car on casse un mécanisme pour le remplacer par un autre, mais qui devra rester compatible... :aie:

Bref cela risque de ne pas forcément être tip-top... :?

Si c'était une proposition pour un nouveau langage j'aurais surement dit oui mais là...

Citation:

---

Envoyé par bulbo

Code:

---

1 2	@bean_property private String name

---

et générer avec l'annotation le code qui va bien pour faire ce que tu veux.

---

Sauf qu'une annotation ne peut pas modifier le code source dans laquelle elle se trouve ;)

a++

Voté pour. C'est vrai que certains éditeurs permettent d'écrire les getters et les setters en quelques click, mais je trouve que ça rendrait quand même le code plus lisible.

Citation:

---

Envoyé par verbose

Voté pour. C'est vrai que certains éditeurs permettent d'écrire les getters et les setters en quelques click, mais je trouve que ça rendrait quand même le code plus lisible.

---

Oui, ce n'est clairement pas pour gagner quelques secondes à leur génération, mais voir 200 lignes de getters / setters dans un bean, je trouve ça indigeste...

Si ce n'est que ça, on pourrait imaginer un "include"

Un petit pour mais à condition que cela soit personnalisable (niveaux de visibilité, read/write, ajout de code spécifique).

Citation:

---

Envoyé par eclesia

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

---

Ben ca fera 44 erreurs à la compilation si ta property date de Mathusalem.

Le nombre de fois où j'ai modifié 44 fois de trucs... Le pire, c'est le jour où je me suis aperçu que j'avais inversé les Pattern Facade et Monteur. J'ai tout renommé, Netbeans a foutu des Monteur dans des package Facade, sans parler des lignes qui commencaient par Monteur maFacade :mouarf::mouarf::mouarf:. Bon j'arrête de pleurer sur mon sort :?

Pour MAIS des proprietes seules sans propagation de PropertyChangeEvent ca ne sert strictement a rien, hors c'est bien le fait de devoir a chaque fois reconstruire la gestion du PropertyChangeSupport + des ajout/retrait de listener + propagation d'evenements dans le setter pour chaque propriete qui est lourdingue (bien plus que de devoir ecrire les setter/getter qui ne sont que du copier/coller en fait).

petit pour parce que les properties façon delphi et C# sont un très bon moyen de coder de maniere encore plus abstrait.

En contre partie, j'aime bien le standard de Java de tout faire commencer par get et set car ceci combiné à la completion automatique de certains IDE me permettent de savoir tout de suite la liste des champs, quelles champs je peux toucher et comment. mais si netbeans me dit si telle prop' est read ou write, alors volontiers pour.

Contre.

Le but des setter et des getter été de pouvoir, de manière transparente, apporter des traitements lors du get et du set.
D'une certaine manière, c'est un contrat, on dit à celui qui utilise notre classe, tu peut récupérer la valeur par getProperty(), mais il ne sais pas si cette property est juste la valeur de l'attribut property ou autre chose.

Pour moi, c'est l'intérêt du principe de Javabean.
Sinon, on fait juste des attributs public!

Citation:

---

Envoyé par woodwai

Contre.

Le but des setter et des getter été de pouvoir, de manière transparente, apporter des traitements lors du get et du set.
D'une certaine manière, c'est un contrat, on dit à celui qui utilise notre classe, tu peut récupérer la valeur par getProperty(), mais il ne sais pas si cette property est juste la valeur de l'attribut property ou autre chose.

Pour moi, c'est l'intérêt du principe de Javabean.
Sinon, on fait juste des attributs public!

---

Pas complètement d'accord avec ça...
Prennons un framework comme JSF. Si je fais "monBean.maPropriete" dans une page XHTML (ou JSP), alors JSF va chercher à utiliser getMaPropriete() et setMaPropriete() et lancera une erreur si je mets juste la visibilité de maPropriete publique, sans fournir son setter / getter.
Si je me retrouve avec 30 propriétés dans mon bean, je vais devoir écrire (ou générer) 60 méthodes, ce qui emcombre (pour rien selon mon avis) ma classe Java...

Je suis de l'avis de Woodwai.

Quant à la remarque de romaintaz, même si je comprend son ennui, c'est LE problème de JSF. C'est JSF qui force l'encapsulation des données et ça devrait être paramétrable si c'est n'est pas le cas.

Citation:

---

Envoyé par bouye

Pour MAIS des proprietes seules sans propagation de PropertyChangeEvent ca ne sert strictement a rien, hors c'est bien le fait de devoir a chaque fois reconstruire la gestion du PropertyChangeSupport + des ajout/retrait de listener + propagation d'evenements dans le setter pour chaque propriete qui est lourdingue (bien plus que de devoir ecrire les setter/getter qui ne sont que du copier/coller en fait).

---

+1
Et les IDE les génèrent facilement les getters/setters.
Je vote CONTRE.

Moi j'ai voté POUR en gardant à l'esprit que cette proposition a pour but de simplifier le code Java, et donc d'améliorer la lisibilité des classes, et non de proposer une nouvelle fonctionnalité à Java...

@benwit: J'ai pris JSF comme exemple, mais ce n'est pas le seul framework...
Maintenant, moi si JSF propose une annotation pour mes propriété par exemple, ça me va très bien !

Ca apporte quoi sémantiquement une property par rapport à une variable d'instance ?

En faite c'est quoi ?

Je comprends pas si on cherche à simplifier l'écriture du code, ou la modelisation, dans notre paradigme objet.