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

bha je ne vois pas en quoi ça pourrait briser l'encapsulation, quand on fait un get() ou un set() on ne brise pas l'encapsulation. Et ça n'est en rien comparable à une transformation en public. Sauf à l'écriture. Par contre le risque est peut-être là.
Ce n'est pas un accès direct, c'est un appel à une méthode générée (si c'est bien copié sur le truc du c#). En lisant le code on aura du mal à voir la différence.

Ensuite,

Si on veut faire un getter et/ou setter bien specifique (ce n'est plus un bean pur on est d'accord), il sera mélangé dans un code où on aura du getter/setter généré et du getter/setter fait à la main. Donc au niveau de

notre code on fera pour la déclaration

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public user{ Date naissance; (<--getter setter specifique) String property nom; (<-- getter setter généré)   getAge() { // calcul de l'age }   setAge(int age) (<-- oui l'exemple est moisi mais j'espère que vous comprenez) { // } }

---

Pour le traitement.

Code:

---

1 2	User user =...; system.out.println(user.nom+ " a aujourd'hui " + user.getAge() + " ans");

---

Je trouve que ça fait brouillon. Surtout que les EDI génèrent super bien tout ça. Contre.

Citation:

---

Envoyé par kisame

bha je ne vois pas en quoi ça pourrait briser l'encapsulation, quand on fait un get() ou un set() on ne brise pas l'encapsulation.

...

---

En fait, je répondais à ceci :

Citation:

---

Envoyé par ITCsoft54

Je ne vois pas vraiment l'intérêt de la chose.

J'ai voté contre.

On fait la même chose avec un :

Code:

---

1 2	Public Type_Variable var;

---

Mettre des "Properties", n'apporte rien. je préfére gardé mes setter et getter, avec au moins on sais où on vas !

si c'est pour rajouter des @set @get et toutes les horreurs du même style pour récupérer les fonctionnalités du getter / setter, alors pourquoi pas tous simplement garder le setter et le getter ?

---

Cela dit, autant nous semblons d'accord sur le principe d'encapsulation, autant nous le sommes moins sur l'aspect "brouillon".

Pour ma part, cela ne me choque pas. En fait, c'est une chose que nous pouvons côtoyer régulièrement lorsque l'on songe aux constructeurs par défaut qui sont générés automatiquement par le compilateur si aucun constructeur n'est écris manuellement pour une classe.

Chris.

Je vote Contre ...

J'ai trouvé ca tout a fait super au debut, tant ca me gon... de devoir me taper la redaction de tout ces assesseurs... mais cela pose quand même pas mal de soucis.

Comme on peut la constater a la lecture de ce thread, cette seul proposition ne peut pas suffire... puisqu'il est nécessaire que l'on puisse contrôler la porté de la propriété et de ses deux assesseurs. Malheureusement, aucune proposition faites ici ne m'a convaincu et je tire de ce constat l'idée qu'il n'y a sans doute pas de façon simple, évidente et indiscutable.

En conséquence, cela veut dire que la vrai façon simple, claire et indiscutable de définir une propriété passe encore par la définition manuelle les assesseur.

Ainsi, entre :

Code:

---

1 2 3 4

@access read public @access write protected public String forename;

---

et

Code:

---

1 2 3 4 5

public String forename = null ;   public String getForename() { return forename ;} public void setForename(String s) { forename = s ;}

---

Je préférè encore la seconde.

Cette modification ne vise qu'au confort et n'apporte rien en terme de qualité logiciel. Par principe, seul ce dernier critère est important dans le cadre de l'évolution du langage. Les aspect "Confort" peuvent, bien mieux, être addréssé par les EDI, les fonctionnalité avancé d'Eclipse en sont une trés bonne illustration.

Je suis totalement contre car à la relecture d'un code on ne pourra plus savoir au premier coup oeil si on accède à une proriété public ou à un getter(/setter) auto généré. A partir de ce moment là, maintenir du code imposant (plusieurs milliers des ligne de code) va vite devenir difficile pour celui qui n'est pas à l'origine de la définition de la classe. Et prire encore, s'il une propriété devait impérativement être au plus protected et que le développeur l'a mise public, la détection de ce bug va être très délicate.

Encore une fois, ça ne sert strictement à rien étant donné que les IDE comme NetBean ou Eclispe font ça très bien. Ca ne ferait que rajouter de la confusion.

un petit exemple :

Code:

---

1 2 3 4 5

public class A {   public String propB; public property String propA; }

---

dans une autre classe :

Code:

---

1 2 3 4 5 6 7 8 9

public class B { private A a; public void methodeB(...) { .... a.propB = "C"; ..... a.propA = "D"; } }

---

Bonjour,

Pour moi les méthodes get/set ne servent à rien si on fait comme en C#:


public String nom;

peut devenir

public String nom {
get { return "..."+m_nom;}
set { m_nom = value;}
}

--> Un champ qui ne contient pas de code métier peut en contenir dans une nouvelle version...


Je ne vois pas pourquoi vous voulez absolument voir la différence entre une propriété et un champ public?

Je suis contre.

Pour avoir utilisé C#, je pense que l'utilisation des propriétés n'est pas plus simple ni plus claire que les accesseurs. En plus la restriction de l'accès n'est pas évidente et l'utilisation de la variable tombée du ciel value encore moins :triste:.

Les propriétés seraient à considérer dans Java 7 comme un nouveau type d'éléments (entre membre et méthode), comme c'est le cas dans C#. C'est vraiment une lourde modif qui est non compatible avec les anciennes versions.

Je pense que la puissance de java est de pouvoir tout faire avec un minimum d'instructions. Il ne faut pas avoir peur des lignes de codes, surtout avec les magnifiques IDE comme Eclipse :king:.

PS : d'ailleurs, comment faire appel au membre privé une fois que c'est une propriété?

Oui, cette value est un petit peu tombee du ciel, je preferais quelque chose comme:

Code:

---

1 2 3 4 5

public String nom { get { return "..."+m_nom;} set(val) { m_nom = val;} }

---

Mais, en general, je pense, que C# est vraiment plus simple et elegant que Java, qui a touts ces setters et getters. Je suis d'accord avec l'idee des props, et on peut disputer la syntaxe apres.

TPReal.

contre: introduction d'un keyword qui est potentiellement aussi utilisé comme nom de variable, et de plus on abolli la séparation entre variable et méthode. Résutat, si je tappe point.x, je dois maitenant m'attendre à ce que x soit une "property" a laquelle est associé du code qui peut potentiellement lever un chiée de runtimeExceptions

Je suis plutôt contre pour la clarté du code (comme dit précédement) mais aussi parce que risque d'embrouiller le dev avec des API tels que que Hibernate Annotations

Citation:

---

Envoyé par tchize_

contre: introduction d'un keyword qui est potentiellement aussi utilisé comme nom de variable, et de plus on abolli la séparation entre variable et méthode. Résutat, si je tappe point.x, je dois maitenant m'attendre à ce que x soit une "property" a laquelle est associé du code qui peut potentiellement lever un chiée de runtimeExceptions

---

Détrompez-moi, mais je n’ai pas du tout compris cela.
Il n’est pas question de pouvoir accéder à une variable d’instance sous la forme « point.x », mais « point.getX() » sachant que, pour le coup, nous ne serions plus obliger de rédiger explicitement cette méthode alors qu’elle ne doit contenir (dans l’immédiat) aucune plus-value.

Chris.

L'idée de base est séduisante : s'épargner l'écriture de tous les getters et setters. Mais pourquoi avoir une vision réduite aux seuls getters et setters. Il ya surement plein d'autres tâches récurentes, spécifiques aux besoins de chacuns. L'idée serait donc de spécifier ce que l'on désire générer automatiquement, avec précision. Plutôt que d'inventer une solution, je suggère de s'inspirer de ce qui se fait dans le domaine de la transformation de modèle. Imaginons le concept d'injecteur, décris de manière déclarative (ie., à base de règles). Certains injecteurs seront définis par l'utilisateur, d'autres fournis en standard avec le JDK. Ce serait typiquement le cas pour l'injection automatique des getters/setters par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

injector generateGetterSetter {   rule attribute2Getter { from : attribute to : method ( visibility<-public, name<-"get"+attribute.name, parameters<-null, body<-"return this."+attribute.name, return<-attribute.type ) }   //... ici même idée pour générer les setters

---

L'utilisation ou non d'un injecteur se ferais à l'aide d'une annotation, comme suit :

Code:

---

1 2 3 4 5 6 7

@injector generateGetterSetter public class Essai {   public int var1; private boolean var2; }

---

Evidemment, cela demanderai un outillage particulier du compilateur, de la même façon que les propositions évoqués au cours de ce topic. Le mérite est simplement de généraliser l'approche à tout ce qui peut être jugé redondant dans l'écriture de code Java. Par ailleurs, les injecteurs étant spécifié à part, ils ne "parasiterai" pas le code de base.

ton idée est interressante, mais on tombe dans la génération de code Ca peut être vachement évolué et, à mon avis, çà n'a rien à faire dans la grammaire java. Si tu veux te faciliter la vie avec des outils libre à toi, mais il n'est pas nécessaire de surcharger le compilateur avec çà. D'une manière générale, je considère que ja génération automatique de getters/setters, c'est le job de l'ide pas celui du compilateur. J'ai beaucoup de fois du faire appel au generate getters/setters de eclipse et franchement, je préfère savoir les méthodes là avec leur code que de voir un flag sur un champ private au fond d'une classe. De plus, quid de la javadoc? On met la javadoc sur le champ privé? Oui mais la doc "privée" n'est souvent pas la même que celle des getters / setters. Le comportement interne de la classe, qui est peut être décrit dans la javadoc du champ private, n'est pas nécessairement utile pour celui qui appelle le getter.

C'est vrai, ce que tchize a dit, que on n'a pas besoin des options bizarres etranges du Java si on a un bon IDE. Dans Eclipse, c'est vraiment facile d'ajouter des setters et getters automatiquement. Ca fait la grande difference, quel IDE on utilise.

Après coup, je suis plutôt d'accord avec toi pour dire que cette machinerie doit être associé à un IDE, plutôt qu'au JDK. Néanmoins, ma remarque reste la même : Eclipse (pour ne citer que lui) permet une génération de getter et setter prédéfinie : imposible de customiser cette génération automatique ni même de spécifier d'autre génération sur-mesure. C'est donc finalement plus une proposition pour les IDEs que pour le JDK en lui-même, ce qui sort du sujet de ce topic.

Alors, pas de besoin de modifier Java ici :)
Mais pour moi, Eclipse est tres customisable. On peut changer quelques choses dans Code Templates, et on peut ajouter les snippets qui sont tres utiles. Moi, je n'ai pas besoin de rien plus.

Il me semble que les getters/setters, tout comme les try catch et autres codes générés sont customizable dans eclipse :)

Plutôt favorable à condition qu'il y ait une annotation plutôt qu'un mot clé. Dans l'esprit, ca reviendrait à déléguer à l'IDE la réécriture du code ainsi que les changements de nom en cas de refactoring.

Par contre pour spécifier le read-write, c'est plus compliqué. Je suis foncierement opposé à l'idée de Remi parceque ca s'éloigne bien trop de la syntaxe traditionnelle du Java.

Il me semble que le plus clair, c'est les annotations @read, @write, @read-write.

parceque public static final property String myProperty get set, ca devient lourd :)

Je suis plutot d'accord pour dire que les getter et setter sont souvent pénibles, surtout dans une appli avec des formulaires fréquents comme c'est le cas chez moi.

Contre pour une raison toute simple : on commence la déclaration par public. Je ne peux pas m'empêcher de penser qu'on part pas dans la bonne direction dès que je vois ça.

Code:

---

1 2 3 4 5

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

---

Les getter et les setter peuvent paraître tous les mêmes au début, mais plus le projet avance ou quand on commence la maintenance il arrive vite qu'il y ai rajout de test à l'intérieur des setter ou d'initialisation dans les setters.

Je trouve qu'une partie non négligeable des propositions sur ce java 7 sont des raccourcis (dangereux) de code qui rendent le code moins clair.

Contre.

On est au 21ème siècle : les EDI se chargent très bien de générer puis masquer se genre de choses.
Pour moi la syntaxe d'un langage doit rester la plus simple possible et Java s'éloigne de plus en plus de ça...

Pour moi le fait qu'une EDI face quelque chose n'est pas une excuse pour que ce soit mal géré par le langage. Les properties sont clairement quelque chose d'indispensable en Java et le fait que ce ne soit pas géré directement par le langage lui même est une véritable lacune.

Et puis même avec Eclipse ou Netbeans pour nous aider à générer tout ce code, ça n'en reste pas moins une surcharge inutile, source de bug et de code peu lisible.