+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Responsable Java

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    11 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 11 930
    Points : 58 081
    Points
    58 081

    Par défaut Tutoriel pour une prise en main de la bibliothèque Lombok pour simplifier l'écriture des classes Java

    Bonjour,

    La société Netapsys nous propose un tutoriel concernant une première prise en main de la bibliothèque Lombok. Cette bibliothèque permet de simplifier l'écriture des classes Java.

    Voici le lien du tutoriel : http://netapsys.developpez.com/tutor...mbok-pratique/

    Profitez de cette discussion pour laisser vos commentaires

    Mickael pour l'équipe Java de Developpez.com

    Retrouvez les meilleurs cours et tutoriels pour apprendre Java
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de cours : mbaron.developpez.com
    Blog : keulkeul.blogspot.com
    LinkedIn : https://www.linkedin.com/in/mickaelbaron
    Twitter : www.twitter.com/mickaelbaron

  2. #2
    Membre habitué
    Homme Profil pro
    Architecte senior Java EE/Spring - ScrumMaster
    Inscrit en
    juin 2010
    Messages
    229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : Architecte senior Java EE/Spring - ScrumMaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2010
    Messages : 229
    Points : 167
    Points
    167

    Par défaut Pattern Logger Factory

    Bonjour, merci pour cette synthèse !
    Une petite remarque concernant les erreurs de copier-coller sur les logger factories. Vos ennuis viennent, je pense, d'une mauvaise compréhension du pattern singleton :
    La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(this.getClass());

  3. #3
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 679
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 679
    Points : 8 752
    Points
    8 752
    Billets dans le blog
    1

    Par défaut

    Ce genre d'outil me laisse pantois...
    Les affirmations du genre "le getter/setter, hashCode() etc... dont l'implémentation ne nécessite normalement aucune réflexion particulière" n'engagent que l'auteur.

    Chez nous, le hashCode est généré en fonction de la clé primaire pour bien des classes (ou super.hashCode() quand elle est nulle)
    La méthode toString() ne contient que des informations utiles pour voir sur quoi on est dans le debug, si on devait se taper les 250 attributs des grosses classes, bonjour la lisibilité !
    La méthode equals() est également dépendante de la clé primaire dans certains cas...
    Le setter est souvent utilisé pour positionner un flag de changement de valeur...
    Et qu'en est-il au niveau du debug si le source ne contient pas les méthodes ?

    Bref, si le but est d'en faire un minimum, soit, c'est l'outil qu'il faut
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Membre habitué
    Homme Profil pro
    Architecte senior Java EE/Spring - ScrumMaster
    Inscrit en
    juin 2010
    Messages
    229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : Architecte senior Java EE/Spring - ScrumMaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2010
    Messages : 229
    Points : 167
    Points
    167

    Par défaut

    Toutes les personnalisations sont prévues (champs à utiliser dans tel ou tel cas). Les méthodes implémentées manuellement ne sont pas surchargées. Bref, quand on veut bosser, Lombok ne l'empêche pas.
    L'ESSAYER, c'est l'adopter.

    Citation Envoyé par OButterlin Voir le message
    ...
    Chez nous, le hashCode est généré en fonction de la clé primaire pour bien des classes (ou super.hashCode() quand elle est nulle)
    La méthode toString() ne contient que des informations utiles pour voir sur quoi on est dans le debug, si on devait se taper les 250 attributs des grosses classes, bonjour la lisibilité !
    La méthode equals() est également dépendante de la clé primaire dans certains cas...
    Le setter est souvent utilisé pour positionner un flag de changement de valeur...
    Et qu'en est-il au niveau du debug si le source ne contient pas les méthodes ?
    ...

  5. #5
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : février 2017
    Messages : 23
    Points : 97
    Points
    97

    Par défaut Haaaa ??!!

    Citation Envoyé par ThomasEscolan Voir le message
    Bonjour, merci pour cette synthèse !
    Une petite remarque concernant les erreurs de copier-coller sur les logger factories. Vos ennuis viennent, je pense, d'une mauvaise compréhension du pattern singleton :
    La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(this.getClass());
    Sérieux ? Ben j'aurais au moins appris quelque chose aujourd'hui. Merci pour l'info

    Concernant Lombok, de manière générale, je suis aussi un peu dubitatif face à ce genre d'outils. Pour moi ça amène plus de risque que d'avantage..

    Générer des getters/setters mon IDE le fait très bien. Je veux dire par là que c'est vraiment pas un gros gain en terme de temps de travail. De plus, en cas de débogage, je pense que cela peux amener de la confusion dans certains cas (p. ex. s'il y a déjà X proxies sur la classe ou des aspects sur la méthode).

    De plus, à mon sens, equals(), hashCode() ou toString() sont tout sauf des méthodes anodines qui peuvent forcément être générées de manière uniforme. et encore une fois, le fait de les générer via l'IDE permet un meilleur contrôle sur le code.

    En pratique, je préfère limiter la génération/l'injection de code au élément qui présente un intérêt majeur.

    Encore une fois c'est un avis général, probablement que dans certains cas ça peut amener une plus-value.

  6. #6
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 131
    Points : 3 289
    Points
    3 289

    Par défaut

    Citation Envoyé par ThomasEscolan Voir le message
    La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :
    Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

    Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

    PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?

    Sinon, pour le reste de Lombok, personnellement je n'y vois aucun intérêt. ça facilite la gestion de code qui est de toute façon plutôt facile à écrire et comprendre, en ajoutant une couche de magie qui posera rapidement plus de problème qu'elle n'en résoud... et si il faut en plus installer des plugins pour avoir une chance que l'IDE soit content.... bah voilà quoi, perso ce n'est pas une option
    "Si tu avoir un problème et choisir regexp comme solution, maintenant tu avoir 2 problèmes"

    Confucius, 448 av. J-C

  7. #7
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : février 2017
    Messages : 23
    Points : 97
    Points
    97

    Par défaut En fait l'idéel ce serait....

    Citation Envoyé par Pill_S Voir le message
    Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

    Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

    PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?

    Sinon, pour le reste de Lombok, personnellement je n'y vois aucun intérêt. ça facilite la gestion de code qui est de toute façon plutôt facile à écrire et comprendre, en ajoutant une couche de magie qui posera rapidement plus de problème qu'elle n'en résoud... et si il faut en plus installer des plugins pour avoir une chance que l'IDE soit content.... bah voilà quoi, perso ce n'est pas une option
    De déclarer les logger de la manière suivante :
    private final Logger logger = LoggerFactory.getLogger(MyClass.class);
    private final Logger logger = LoggerFactory.getLogger(MyAbstractClass.class);

    Du coup plus de static pour les classes non-statiques et plus de problème de logger qui ne 'logguent' pas la bonne classe.
    Pour le coup du context statique ben ma foi logger static...

    Mais on s'écarte du sujet original

  8. #8
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 131
    Points : 3 289
    Points
    3 289

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    De déclarer les logger de la manière suivante :
    private final Logger logger = LoggerFactory.getLogger(MyClass.class);
    private final Logger logger = LoggerFactory.getLogger(MyAbstractClass.class);
    ... ce qui n'évite du coup plus les problème de copier-coller...

    Citation Envoyé par GordonFreeman Voir le message
    Mais on s'écarte du sujet original
    Certes
    "Si tu avoir un problème et choisir regexp comme solution, maintenant tu avoir 2 problèmes"

    Confucius, 448 av. J-C

  9. #9
    Membre habitué
    Homme Profil pro
    Architecte senior Java EE/Spring - ScrumMaster
    Inscrit en
    juin 2010
    Messages
    229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : Architecte senior Java EE/Spring - ScrumMaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2010
    Messages : 229
    Points : 167
    Points
    167

    Par défaut

    Citation Envoyé par Pill_S Voir le message
    Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

    Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

    PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?
    Dans ce cas, je suggère d'utiliser l'annotation @Slf4j ou une de ses cousines, fournies par... Lombok ;-)

Discussions similaires

  1. [WD-2010] Bilan d'une prise en main de plusieurs mois
    Par sekaijin dans le forum Word
    Réponses: 0
    Dernier message: 19/11/2014, 18h16
  2. Réponses: 5
    Dernier message: 29/07/2011, 16h03
  3. Réponses: 1
    Dernier message: 10/08/2010, 15h37
  4. Aide pour la prise en main du Protocole MODBUS/JBUS
    Par homeostasie dans le forum MFC
    Réponses: 24
    Dernier message: 20/05/2006, 15h56

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