IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Êtes-vous pour ou contre cette proposition ?

Votants
332. Vous ne pouvez pas participer à ce sondage.
  • Pour

    185 55,72%
  • Contre

    147 44,28%
Langage Java Discussion :

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


Sujet :

Langage Java

  1. #101
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 144
    Points
    144
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  2. #102
    Membre averti

    Profil pro
    Coach Agile
    Inscrit en
    Décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Points : 371
    Points
    371
    Par défaut
    Citation Envoyé par kisame Voir le message
    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 Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  3. #103
    Membre à l'essai
    Profil pro
    Architecte de système d’information
    Inscrit en
    Février 2008
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d’information

    Informations forums :
    Inscription : Février 2008
    Messages : 13
    Points : 16
    Points
    16
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
     @access read public
     @access write protected
     public String forename;
    et

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  4. #104
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2007
    Messages
    15
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 15
    Points : 26
    Points
    26
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public class A {
     
     public String propB;
     public property String propA;
    }
    dans une autre classe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    public class B {
      private A a;
      public void methodeB(...) {
      ....
      a.propB = "C";
      .....
      a.propA = "D";
      }
    }

  5. #105
    Nouveau membre du Club
    Inscrit en
    Janvier 2007
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : Janvier 2007
    Messages : 48
    Points : 28
    Points
    28
    Par défaut
    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?

  6. #106
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mars 2008
    Messages : 20
    Points : 30
    Points
    30
    Par défaut pas comme C# svp
    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 .

    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 .

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

  7. #107
    Membre à l'essai
    Inscrit en
    Novembre 2007
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Novembre 2007
    Messages : 17
    Points : 21
    Points
    21
    Par défaut
    Oui, cette value est un petit peu tombee du ciel, je preferais quelque chose comme:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  8. #108
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    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

  9. #109
    Membre actif
    Avatar de repié
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    335
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Décembre 2004
    Messages : 335
    Points : 281
    Points
    281
    Par défaut
    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
    Pti Pié

  10. #110
    Membre averti

    Profil pro
    Coach Agile
    Inscrit en
    Décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Points : 371
    Points
    371
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    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.

  11. #111
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Points : 4 166
    Points
    4 166
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 java : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  12. #112
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    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.

  13. #113
    Membre à l'essai
    Inscrit en
    Novembre 2007
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Novembre 2007
    Messages : 17
    Points : 21
    Points
    21
    Par défaut
    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.

  14. #114
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Points : 4 166
    Points
    4 166
    Par défaut
    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.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  15. #115
    Membre à l'essai
    Inscrit en
    Novembre 2007
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Novembre 2007
    Messages : 17
    Points : 21
    Points
    21
    Par défaut
    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.

  16. #116
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Il me semble que les getters/setters, tout comme les try catch et autres codes générés sont customizable dans eclipse

  17. #117
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    Juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Points : 1 267
    Points
    1 267
    Par défaut
    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.

  18. #118
    Membre régulier
    Profil pro
    Développeur Java
    Inscrit en
    Août 2007
    Messages
    58
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 58
    Points : 92
    Points
    92
    Par défaut
    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 : 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;
    }
    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.

  19. #119
    Inactif  
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    357
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2008
    Messages : 357
    Points : 637
    Points
    637
    Par défaut
    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...

  20. #120
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

Discussions similaires

  1. Réponses: 27
    Dernier message: 19/10/2008, 12h51
  2. JDK 7: Proposition 13 : Accès aisé aux propriétés
    Par vbrabant dans le forum Langage
    Réponses: 93
    Dernier message: 16/10/2008, 19h14
  3. recopie des propriétés d'un composant
    Par pitounette dans le forum C++Builder
    Réponses: 2
    Dernier message: 20/02/2004, 11h40
  4. Comment cacher des propriétés dans un nouvel objet ?
    Par Pedro dans le forum Composants VCL
    Réponses: 2
    Dernier message: 22/10/2003, 19h53
  5. ouverture de la fenêtre des propriétés afffichage
    Par Mercilius dans le forum API, COM et SDKs
    Réponses: 4
    Dernier message: 26/03/2003, 18h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo