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

  1. #101
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par micka132 Voir le message
    En fait il n'y a pas de confusion si on respecte la norme en c#.
    Un champ public ne devrait pas exister, il faut toujours créer une propriété (avec une majuscule nomObjet.Nom). D'ailleurs sous visual studio le snippet prop ou propfull est bien pratique.
    Si le langage autorise les champs en public c'est certainement pour des cas bien particuliers où tu as un besoin de performance (la propriété est forcement un peu plus lourde) et que tu es certain que l'accès ou l'affectation de ton champ n'entrainera jamais de traitement.
    Mais quand bien même la norme n'est pas respectée, qu'est-ce qui te chagrine dans le fait de ne pas savoir si c'est un champ ou une propriété?
    Ha oui juste, c'est des majuscules en C# ^^
    Alors affectivement les champs public ne devrait jamais être utilisé hormis quelque cas bien précis, comme tu dis par besoin de perf ou autre.
    Mais on sait tous très bien que le respect des règles et des bonnes pratiques n'est pas toujours top. En fait, quand on se ramasse un projet, on peut tomber sur tout et son contraire.

    Je rebondis juste sur ta dernière phrase;
    Citation Envoyé par micka132 Voir le message
    Mais quand bien même la norme n'est pas respectée, qu'est-ce qui te chagrine dans le fait de ne pas savoir si c'est un champ ou une propriété?
    Ce qui me dérange ? Simplement le fait de ne pas savoir! Alors qu'avec un getter/setter je le sais tout de suite (et j'irais mettre une petite gueulante au mec qui à fait ça histoire de lui rappeler les concepts de base de la POO)).

    Donc encore une fois je pense que c'est un sucre syntaxique qui amène plus de confusion que d'avantage par rapport au getter/setter..
    C'est pour ça que je suis pas fan. Mais ça s’arrête la hein, y'a pas mort d'homme

  2. #102
    Membre habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 47
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Concernant les properties (comme en C# p. ex.), personnellement je suis contre (encore plus depuis que j'ai du les utiliser).
    La raison est simple, avec les properties on ne sait pas si on tape sur un champ public (le mal) ou sur un getter (ex nomObjet.nom).
    A mon sens c'est un sucre syntaxique qui amène de l’ambiguïté plus qu'autre chose.

    Et si vraiment faire générer les getter/setter par ton EDI est encore trop chiant, il y a des outils comme 'Lombok' (je ne suis pas fan non plus) qui vont te générer automatiquement tout tes getter et tes setters.
    Heu, je viens de voir cette réponse et 2 posts précédents, et je crois qu'il y ai une incompréhension du paradigme Objet. Lorsque vous utilisez un objet, vous n'avez à connaitre que l'interface, qu'il s'agisse d'un attribut ou d'une méthode. Si il s'agit d'un attribut, peu importe si il s'agit réellement d'un attribut ou d'une property. C'est les principes de base de l'encapsulation et de l'abstraction.

    De base, les getters/setters sont une aberration, mais une aberration nécessaire pour les langages n'implémentant pas la notion de properties/attributs calculés afin qu'ils puissent mettre en œuvre une granularité plus fine de la visibilité en respectant le principe de l'accès uniforme. En fait, pour ma part, j'évite les temres "get" et "set" au maximum. Car dans la pratique, ils conduisent à votre principe, c'est à dire un passe-plat entre l'extérieur et vos attributs réels. Et on a alors un fort couplage entre l'interface et l'implémentation, une violation du principe de l'encapsulation et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire. Mais c'est un type de code que l'on voit régulièrement parmi ceux qui adoptent le paradigme procédural, qui est à mon sens le plus utilisé aujourd'hui et certainement le plus utilisé dans le monde Java.

  3. #103
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    Heu, je viens de voir cette réponse et 2 posts précédents, et je crois qu'il y ai une incompréhension du paradigme Objet. Lorsque vous utilisez un objet, vous n'avez à connaitre que l'interface, qu'il s'agisse d'un attribut ou d'une méthode. Si il s'agit d'un attribut, peu importe si il s'agit réellement d'un attribut ou d'une property. C'est les principes de base de l'encapsulation et de l'abstraction.

    De base, les getters/setters sont une aberration, mais une aberration nécessaire pour les langages n'implémentant pas la notion de properties/attributs calculés afin qu'ils puissent mettre en œuvre une granularité plus fine de la visibilité en respectant le principe de l'accès uniforme. En fait, pour ma part, j'évite les temres "get" et "set" au maximum. Car dans la pratique, ils conduisent à votre principe, c'est à dire un passe-plat entre l'extérieur et vos attributs réels. Et on a alors un fort couplage entre l'interface et l'implémentation, une violation du principe de l'encapsulation et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire. Mais c'est un type de code que l'on voit régulièrement parmi ceux qui adoptent le paradigme procédural, qui est à mon sens le plus utilisé aujourd'hui et certainement le plus utilisé dans le monde Java.
    Heu... Honnêtement j'ai pas tout compris et il me semble qu'il y a beaucoup d'erreurs dans vos affirmations...

    Citation Envoyé par dad3zero Voir le message
    je crois qu'il y ai une incompréhension du paradigme Objet. Lorsque vous utilisez un objet, vous n'avez à connaitre que l'interface, qu'il s'agisse d'un attribut ou d'une méthode. Si il s'agit d'un attribut, peu importe si il s'agit réellement d'un attribut ou d'une property. C'est les principes de base de l'encapsulation et de l'abstraction.
    Non, le principe d'encapsulation est le fait de ne pas exposer les données mais de proposer des méthodes pour les manipuler. Donc exposer des champs public casse direct le principe d'encapsulation.
    Et oui, je n'ai à connaitre que l'interface, et dans une interface j'expose des méthodes (les getter que je désire également), pas des champs public. Ce n'est pas une raison pour exposer des données dans les implémentations des objets.
    Citation Envoyé par dad3zero Voir le message
    De base, les getters/setters sont une aberration, mais une aberration nécessaire pour les langages n'implémentant pas la notion de properties/attributs calculés afin qu'ils puissent mettre en œuvre une granularité plus fine de la visibilité en respectant le principe de l'accès uniforme. En fait, pour ma part, j'évite les temres "get" et "set" au maximum. Car dans la pratique, ils conduisent à votre principe, c'est à dire un passe-plat entre l'extérieur et vos attributs réels.
    Non, les getter et setter sont la pour donner accès au données de l'objet (je ne comprend pas cette histoire de visibilité, je travail avec des interface donc j'expose des méthodes public).
    Effectivement les getter/ setter sont des passes plats, comme les properties, la seul chose qui diffère est le nommage. Ou alors j'ai loupé qqch ?

    Citation Envoyé par dad3zero Voir le message
    Car dans la pratique, ils conduisent à votre principe, c'est à dire un passe-plat entre l'extérieur et vos attributs réels. Et on a alors un fort couplage entre l'interface et l'implémentation, une violation du principe de l'encapsulation et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire. Mais c'est un type de code que l'on voit régulièrement parmi ceux qui adoptent le paradigme procédural, qui est à mon sens le plus utilisé aujourd'hui et certainement le plus utilisé dans le monde Java.
    La je n'y comprend plus rien à votre théorie...
    Il n'y a aucun rapport et encore moins de couplage du au fait d'utiliser des getter/setter !!! Comment pourrait-il y avoir un couplage entre l'interface et l'implémentation ?? Qui plus est provoqué pardes getter/setters ???
    et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire ça n'a ni queue ni tête ceci !?

    Et concernant ceci : le paradigme procédural, qui est à mon sens le plus utilisé aujourd'hui et certainement le plus utilisé dans le monde Java. Heu ..... Java est un langage pur Object (abstraction, encapsulation, héritage et polymorphisme))(avec d'autres concept comme la POA, générique, fonctionnelle,etc), mais en tout cas pas procédurale!! On n'appel pas de fonction/routine à tout va sur des modules a gauche à droite avec des variable globales. C'est un ensemble d'objet structurés qui ont des états et qui communiquent par le biais de messages.

    Encapsulation : https://fr.wikibooks.org/wiki/Progra.../Encapsulation
    Paradigme procédurale : https://fr.wikipedia.org/wiki/Progra...oc%C3%A9durale

    Honnêtement, comme je vous les dis plus haut il y a beaucoup d’amalgames et d'erreurs dans vos affirmation ...

  4. #104
    Membre habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 47
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Non, le principe d'encapsulation est le fait de ne pas exposer les données mais de proposer des méthodes pour les manipuler.
    Non, le principe de l'encapsulation est le principe selon lequel un objet doit masquer son implémentation et communiquer uniquement avec les attributs et méthodes publiques.

    (je ne comprend pas cette histoire de visibilité, je travail avec des interface donc j'expose des méthodes public).
    C'est pourtant la base du paradigme objet, la définition publique ou privée est absolue, vous ne pouvez définir une visibilité publique en lecture et privée en écriture.

    Effectivement les getter/ setter sont des passes plats, comme les properties, la seul chose qui diffère est le nommage. Ou alors j'ai loupé qqch ?
    Oui, ce sont des fonctions (enfin, "méthodes").

    Il n'y a aucun rapport et encore moins de couplage du au fait d'utiliser des getter/setter !!! Comment pourrait-il y avoir un couplage entre l'interface et l'implémentation ?? Qui plus est provoqué pardes getter/setters ???
    C'est vous qui vous l'imposez par votre principe de miroir entre les getters/setters et les attributs.

    et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire ça n'a ni queue ni tête ceci !?
    Pourtant, pour une approche basique c'est ce qui est défini par le O du SOLID de R. Martin

    Java est un langage pur Object (abstraction, encapsulation, héritage et polymorphisme))(avec d'autres concept comme la POA, générique, fonctionnelle,etc), mais en tout cas pas procédurale!!
    Java est un langage qui techniquement utilise des objets. Programmation procédurale et Programmation Orientée Objet sont des paradigmes de programmation, ne confondez pas les deux. Dans une approche POO, on conçoit des composants ayant un état ET des comportements.

    Encapsulation : https://fr.wikibooks.org/wiki/Progra.../Encapsulation
    Paradigme procédurale : https://fr.wikipedia.org/wiki/Progra...oc%C3%A9durale

    Honnêtement, comme je vous les dis plus haut il y a beaucoup d’amalgames et d'erreurs dans vos affirmation ...
    En fait, il y n'y en a aucun si on se base sur la littérature informatique et non sur Wikipedia…

  5. #105
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Non, le principe de l'encapsulation est le principe selon lequel un objet doit masquer son implémentation et communiquer uniquement avec les attributs et méthodes publiques.
    Pas d'accord, on n'expose pas les propriété d'un objet, on les manipule via les méthodes afin de maintenir la cohérence des données et c'est un des fondamentaux de la POO! Sinon on expose tout et pas de getter/setter ni de properties.

    C'est pourtant la base du paradigme objet, la définition publique ou privée est absolue, vous ne pouvez définir une visibilité publique en lecture et privée en écriture.
    Oui ça fait partie des concept objet, je n'ai jamais dit le contraire...

    Oui, ce sont des fonctions (enfin, "méthodes").
    Voilà, donc sucre syntaxique qui ne change rien à la problématique (c'est la ou je ne comprend pas les problèmes que vous citez liés au getter/setter)

    C'est vous qui vous l'imposez par votre principe de miroir entre les getters/setters et les attributs.
    Encore une fois je ne comprend pas le rapport... Et la différence par rapport aux getter/setters

    Pourtant, pour une approche basique c'est ce qui est défini par le O du SOLID de R. Martin
    Oui je connais les principes SOLID et les ouvrages de M. Martin. Mais encore une fois je ne vois pas le rapport... Encore une fois on expose des interface donc je ne vois pas ou la classe ne peut pas évoluer du fait des getter/setter!


    Java est un langage qui techniquement utilise des objets. Programmation procédurale et Programmation Orientée Objet sont des paradigmes de programmation, ne confondez pas les deux. Dans une approche POO, on conçoit des composants ayant un état ET des comportements.

    Mais c'est exactement ce que je vous dit, suite à votre affirmation que Java est procédurale...

    En fait, il y n'y en a aucun si on se base sur la littérature informatique et non sur Wikipedia…
    Oui alors j'ai mis les liens wiki par rapidité/facilité. Mais au final il n'y a pas grande différence avec la littérature spécialisée.

    Pour moi votre premier post est soit mal exprimé, soit il y a un mélange / amalgame ou mauvaise compréhension des concepts cités.
    Pour résumer, je vous laisse le soin de répondre si vous avez envie. Mais je ne pense pas qu'on arrivera à se mettre d'accord (ça ne m'empêchera pas de dormir et de plus on pollue le fil du topic.
    Donc pour ma part je m’arrêterai là.

  6. #106
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Citation Envoyé par dad3zero Voir le message
    Car dans la pratique, ils conduisent à votre principe, c'est à dire un passe-plat entre l'extérieur et vos attributs réels. Et on a alors un fort couplage entre l'interface et l'implémentation, une violation du principe de l'encapsulation et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire. Mais c'est un type de code que l'on voit régulièrement parmi ceux qui adoptent le paradigme procédural, qui est à mon sens le plus utilisé aujourd'hui et certainement le plus utilisé dans le monde Java.
    La je n'y comprend plus rien à votre théorie...
    Il n'y a aucun rapport et encore moins de couplage du au fait d'utiliser des getter/setter !!! Comment pourrait-il y avoir un couplage entre l'interface et l'implémentation ?? Qui plus est provoqué pardes getter/setters ???
    et au final, un code rigide fermé à l'évolution du fait de l'impact en modification nécessaire ça n'a ni queue ni tête ceci !?
    Par exemple, dans une entreprise, admettons que plusieurs programmes utilisent une bibliothèque commune interne à cette entreprise. Cette bibliothèque contient une classe de log LogueurCommun qui a une variable membre privée de type LegacyLogger fournie par une bibliothèque externe. Un jour, on veut se débarrasser de LegacyLogger et on veut la remplacer par NewCoolLogger.

    Si LogueurCommun a la très mauvaise idée d'avoir une fonction publique getLegacyLogger alors, le jour où on voudra faire le changement, il faudra consulter les développeurs responsables des différents logiciels pour demander : « Salut, est-ce que quelqu'un ici appelle cette abominable fonction getLegacyLogger ? Si oui, quelles fonctionnalités de LegacyLogger utilisez-vous ? »

    Si LogueurCommun a plein de méthodes publiques dont certaines qui seraient difficiles à réimplémenter avec NewCoolLogger, alors il faut voir aussi les développeurs pour savoir si on peut simplifier l'interface.

    Par contre, si les méthodes publiques de LogueurCommun se restreignent au nécessaire et qu'il est facile de les réimplémenter après avoir remplacé LegacyLogger par NewCoolLogger, alors on peut mettre à jour l'implémentation de LogueurCommun sans faire de changements non rétrocompatibles dans l'interface et tout le monde est content.

    De manière générale, plus on donne d'informations sur ce qu'il y a sous le capot, moins on a d'encapsulation. Or, les accesseurs (alias getters) et les mutateurs (alias setters) donnent beaucoup d'informations sur ce qu'il y a sous le capot.

    Bien sûr, il y a des cas où les accesseurs sont justifiés. Par exemple, si on crée une classe qui représente un point du plan, alors il est généralement normal d'avoir un accesseur qui retourne l'abscisse et un autre qui retourne l'ordonnée.

  7. #107
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Par exemple, dans une entreprise, admettons que plusieurs programmes utilisent une bibliothèque commune interne à cette entreprise. Cette bibliothèque contient une classe de log LogueurCommun qui a une variable membre privée de type LegacyLogger fournie par une bibliothèque externe. Un jour, on veut se débarrasser de LegacyLogger et on veut la remplacer par NewCoolLogger.

    Si LogueurCommun a la très mauvaise idée d'avoir une fonction publique getLegacyLogger alors, le jour où on voudra faire le changement, il faudra consulter les développeurs responsables des différents logiciels pour demander : « Salut, est-ce que quelqu'un ici appelle cette abominable fonction getLegacyLogger ? Si oui, quelles fonctionnalités de LegacyLogger utilisez-vous ? »

    Si LogueurCommun a plein de méthodes publiques dont certaines qui seraient difficiles à réimplémenter avec NewCoolLogger, alors il faut voir aussi les développeurs pour savoir si on peut simplifier l'interface.

    Par contre, si les méthodes publiques de LogueurCommun se restreignent au nécessaire et qu'il est facile de les réimplémenter après avoir remplacé LegacyLogger par NewCoolLogger, alors on peut mettre à jour l'implémentation de LogueurCommun sans faire de changements non rétrocompatibles dans l'interface et tout le monde est content.

    De manière générale, plus on donne d'informations sur ce qu'il y a sous le capot, moins on a d'encapsulation. Or, les accesseurs (alias getters) et les mutateurs (alias setters) donnent beaucoup d'informations sur ce qu'il y a sous le capot.

    Bien sûr, il y a des cas où les accesseurs sont justifiés. Par exemple, si on crée une classe qui représente un point du plan, alors il est généralement normal d'avoir un accesseur qui retourne l'abscisse et un autre qui retourne l'ordonnée.
    Ha oui bien sur, lui la je suis tout à fait d'accord et convaincu. On n'expose que ce qui est nécessaire! Ce qui me semble logique.

    Ce que je ne comprenait pas, c'est le fait que ce problème soit existant avec des getter/setter et non avec des properties. (selon ce que j'ai compris du post ci-dessus)

    Car il me semble que cette problématique est plutôt un aspect lié à la conception des interface. Le problème n'est pas directement lié aux accesseurs, car on peut exposer des tonnes de méthodes inutiles en ne respectant pas ce principe.
    Comme on peut n'exposer aucun accesseurs dans les interface, même s'il sont implémentés..

  8. #108
    Membre habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 47
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Pas d'accord, on n'expose pas les propriété d'un objet, on les manipule via les méthodes afin de maintenir la cohérence des données et c'est un des fondamentaux de la POO! Sinon on expose tout et pas de getter/setter ni de properties.
    Ok, donc dans vos classes, les setters par exemple contiennent toute la validation métier, lèvent une exception si le paramètre n'est pas valide, c'est bien ça ?

    2 petites question qui vont avec :
    - J'ai un objet de type DAO qui me permet de charger à partir d'une base des "employés", comment appelez-vous la méthode qui me permet d'obtenir une liste de tous les employés ?
    - J'ai un objet représentant disons une BU qui contient un attribut employees de type ArrayList, comment appelez-vous la méthode qui me permet d'obtenir tous les employés et que contient votre return ?

    Sinon, une incompréhension :
    Mais c'est exactement ce que je vous dit, suite à votre affirmation que Java est procédurale...
    Je n'ai pas écris ou voulu écrire que Java est procédural mais que la majorité des développements utilisant le langage Java suivent un paradigme procédural.

  9. #109
    Membre averti
    Inscrit en
    mai 2007
    Messages
    286
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 286
    Points : 385
    Points
    385

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Je ne comprend pas la première partie de ton message sur les framework qui font 'de l'introspection massive' ... Ils n'ont pas vraiment le choix pour aller lire les annotations présentes sur les classes. De plus il n'y a pas forcément de lien avec les getters/setters
    Désolé de ne pas avoir été clair, j'ai voulu trop simplifier alors qu'il y a plusieurs concept qui posent problème avec l'utilisation de l'introspection:
    - d'abord dans un code perso c'est moins maintenable et fiable: Hibernate et Jackson sont tellement éprouvés qu'il n'y a aucune problème de ce côté... sauf quand on veut soulever le capot pour voir comment ça marche ou simplement contribuer.
    - ensuite pour moi ça temoigne d'un manque dans le language, plus ou moins compensés par l'arrivée des lambda qui permet de faire référence à un getter ou un setter, mais pas les 2. Autrement, Il y a aussi un plugin qui permet de générer du code pour JPA pour avoir des meta objet référençant les attribut requetés, mais c'est un outil en plus, à rajouter dans le build, pas intégré dans le langage, être obligé d'ajouter une verrue pour ça, je préfère m'en passer et risquer d'avoir des requetes JPA pourries.
    - Si tu regarde comment sont fait ces framework, et que tu veux implémenter le tient (le but d'un bon langage amha) et bien ça va plus loin que de l'introspection, pour ajouter les hook sur les accesseurs JPA, il faut passer par du byteCode, c'est pas accessible à tout le monde!(jamais fait mais je suis sur que c'est impossible en java pur, à la limite avec les java..instrumentation)

    Citation Envoyé par GordonFreeman Voir le message
    Hibernate s'occupe des entités que tu a explicitement annotés via les annotations javax.persistence. ou hibernate.
    Jackson / JAxB sont des api de sérialisation Json/XML, il est donc clair que tes objets doivent être lu d'une manière ou d'une autre pour être représenté en XML ou autre.
    Spring idem mais sur des annotations qui ont été définie explicitement ( enfin, faut encore voir de quel partie des tools Spring on parle)


    Ce qui m'embête dans ta réponse, c'est le 'alors que tu n'as rien demandé'. Si tu utilise ces API/framework, il faut quand même connaitre leurs façon de travailler et la manière de les utiliser.
    Pour moi rien de choquant, ou alors j'ai loupé un truc ?
    Oui, parfaitement d'accord, mais le 'alors que tu n'as rien demandé' c'est l'homogénéité de l'utilisation, si le langage permettait un hook sur les variables, Et surtout s'il y avait une norme pour son utilisation, on n'aurais pas besoin de consulter la doc de chaque framework pour savoir si le getter qu'on implémente va perturber une sérialisation ou une autre. C'est un point détail d'accord, juste un gain de temps de quelque seconde pour savoir si j'utilise @JsonIgnore ou @Transient, et surtout l'annotation au niveau type. (que j'ai oublié tellement c'est overkill)

    (Un hook du langage pour les variables à l'image du java.lang.reflect.Proxy pour les méthodes, + des annotation intégrées à Java, mais c'est une parenthèse un peu éloigné du sujet il est vrai)

    Bref.. point de détail celui la, si ce n'est qua Java est largement dépendant de ses librairies, alors que dans d'autres langage, la transco JSON est built-in.

    Citation Envoyé par GordonFreeman Voir le message
    Concernant les properties (comme en C# p. ex.), personnellement je suis contre (encore plus depuis que j'ai du les utiliser).
    La raison est simple, avec les properties on ne sait pas si on tape sur un champ public (le mal) ou sur un getter (ex nomObjet.nom).
    A mon sens c'est un sucre syntaxique qui amène de l’ambiguïté plus qu'autre chose.

    Et si vraiment faire générer les getter/setter par ton EDI est encore trop chiant, il y a des outils comme 'Lombok' (je ne suis pas fan non plus) qui vont te générer automatiquement tout tes getter et tes setters.

    M'enfin petite parenthèse hein
    Ah non je déteste les outils de génération de code à la Lombok, effectivement, la génération par l'EDI n'est pas gênante!

    Les properties sont pas forcément la solution oui, mais je n'ai quasiment jamais vu de champ public, en dehors des constantes, c'est une convention assez bien respectée.

  10. #110
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    Ok, donc dans vos classes, les setters par exemple contiennent toute la validation métier, lèvent une exception si le paramètre n'est pas valide, c'est bien ça ?
    Non pas tout, pourquoi supposer ça ? c'est les services qui sont responsable de la validation métier.

    Citation Envoyé par dad3zero Voir le message
    2 petites question qui vont avec :
    - J'ai un objet de type DAO qui me permet de charger à partir d'une base des "employés", comment appelez-vous la méthode qui me permet d'obtenir une liste de tous les employés ?
    - J'ai un objet représentant disons une BU qui contient un attribut employees de type ArrayList, comment appelez-vous la méthode qui me permet d'obtenir tous les employés et que contient votre return ?
    Alors perso je n'utilise pas de DAO, je travail toujours avec des Repository (notion très similaire mais légèrement différente)
    question 1 : public List<Employe> findAll() mais ce n'est pas des méthodes que je m'amuse à écrire, c'est du code générer (par Spring en l’occurrence).
    question 2 : public List<Employe> getEmployes()

    Mais je vois pas trop le but de ces question et le rapport avec le sujet ?

    Citation Envoyé par dad3zero Voir le message
    Sinon, une incompréhension :
    Je n'ai pas écris ou voulu écrire que Java est procédural mais que la majorité des développements utilisant le langage Java suivent un paradigme procédural.
    Pas de soucis, c'est peut être moi qui ai mal interprété ceci [suivent un paradigme procédural] (j'avoue ne pas très bien comprendre cette assertion ).
    Je trouve très dur les discussions techniques par post. Déjà que 2 dev qui discutent de vive voix ont souvent de la peine à se comprendre

  11. #111
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Oui alors je n'aime pas trop voir de code utilisant de l'introspection dans les aplis. C'est bien, c'est puissant, ça fait la magie mais c'est dur à maintenir et risqué.
    Par contre dans un framework je pense que c'est quasi inévitable (je parle de framework comme Spring, Hibernate, etc)


    Concernant JPA, j'utilise un plugin maven qui me générer les meta-model de mes entités. Comme ça il sont toujours alignés par rapport à mes entités et c'est propre. Du coup je peux travailler avec ce qui est quand même beaucoup plus propre pour la génération des requêtes, plus ou très peu de requête sous forme de String et l'utilisation de l'API criteria.
    Pour moi ce n'est pas des manques dans le sens ou Java est un language (une plateforme à la limite) la génération des meta-model est une fonctionnalité spécifique pour un projet donné, du coup tu paramètres ton build en conséquence. L'avantage est que ton build sera normé peu importe quel dev, système ou autre réalise le build. Tu peux le faire via Eclipse mais tu perd certain avantage par rapport au build maven

    Et ce n'est en tous cas pas une verrue que d'utiliser les plugin maven pour ce genre de chose, c'est plutot une bonne pratique. Honnêtement c'est vraiment dommage de s'en passer
    Imagine si Java devait intégrer tous les outils pour tous les cas d'utilisations... Ce serait juste une usina à gaz ingérable.
    De plus, ça à l'avantage de pouvoir utiliser l'API que tu veux en fonction des tes besoins, connaissances, etc. Ça amène de la flexibilité à mon sens.

    Oui effectivement, de souvenir, JaxB et Jackson permettent de spécifier au niveau de la classe comment doivent être sérialiser tes POJO, soit par les attributs, soit par les getter setter. Je ne pense pas que c'est overkill mais il y a une autre solution qui t'éviteras bcp de problème
    C'est d'utiliser des objet dédiés pour la sérialisation, tu n'auras aucun problème de getter, de transient ou autre.
    De plus, je ne sait pas si c'est ce que tu fais mais ce n'est pas très sain de sérialiser des entité JPA.

    Tu parle de hook, de manque du langage, etc. Concernant les hook, il y a la POA. Mais je ne vois pas vraiment l'intérêt pour de la sérialisation


    Citation Envoyé par deltree Voir le message

    Les properties sont pas forcément la solution oui, mais je n'ai quasiment jamais vu de champ public, en dehors des constantes, c'est une convention assez bien respectée.
    Alors je peux t'affirmer que ça se fait. Ou je travaillait avant, un projet de 2,2Millions de LoC, j'en ai vu beaucoup beaucoup trop. Sans parler du reste... Le problème est que les mecs qui avaient développé ça ne connaissait pas grand chose à la POO.
    Et c'est la ou je rejoins dad3zero sur le procédural, les mecs programmait des classe avec UNE méthode, 8500 LoC, et des labels (équivalents à des GOTO)... En fait il faisait des scripts dans les classes

    Tous ça pour dire que seul la connaissance du langage et des outils, rigueur des développeurs et l'analyse du code avec des outils comme Sonar peuvent éviter ces mauvaises pratique, le problème est que ceux qui font ce genre de chose ne sont en général pas rigoureux et n’utilisent pas d'outils d'analyse de code....

  12. #112
    Membre habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 47
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par GordonFreeman Voir le message
    Non pas tout, pourquoi supposer ça ? c'est les services qui sont responsable de la validation métier.
    Heu…*Il y a donc quoi dans un getter/setter ? Un setter type setBirthDate sur un objet Employee ne lève donc pas d'exception si la date est supérieur à aujourd'hui (je dirai même à aujourd'hui il y a 16 ans) ?

    Alors perso je n'utilise pas de DAO, je travail toujours avec des Repository (notion très similaire mais légèrement différente)
    question 1 : public List<Employe> findAll() mais ce n'est pas des méthodes que je m'amuse à écrire, c'est du code générer (par Spring en l’occurrence).
    question 2 : public List<Employe> getEmployes()
    Donc, si j'ai un composant qui fait quelque chose avec des employés, je devrai dupliquer du code pour rendre en compte 2 types différents présentant 2 méthodes différentes et donc avoir une connaissance concrète de ce qu'il y a derrière ? N'est ce pas lourd en maintenance ?

    Et sinon, que contient getEmployees comme code (en supposant les éléments stockés dans un attribut type ArrayList ?

  13. #113
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    Heu…*Il y a donc quoi dans un getter/setter ? Un setter type setBirthDate sur un objet Employee ne lève donc pas d'exception si la date est supérieur à aujourd'hui (je dirai même à aujourd'hui il y a 16 ans) ?
    Alors on est à la frontière avec la date d'anniversaire (plutôt date de naissance...) entre la validation métier ou technique.
    Technique : car il est clair que la date ne peut pas être supérieur à aujourd'hui. Par contre un test technique adapté à l'objet est de tester si la valeur est null dans le cas ou la méthode spécifique pas de null
    Métier : car on pourrait imaginer d'autres contraintes temporelles en fonction du domaine. (ex: qqun qui ouvre un compte dans une banque ne peut pas avoir moins de 18ans. Même que je verrais plutôt cette validation au niveau d'un service..)

    Encore une fois ça dépend du contexte et du type d'objet que l'on manipule. Si c'est un simple DTO utilisé pour de la sérialisation, non pas de validation car ce n'est pas son rôle.
    Dans le cas d'un objet de domaine on pourrait evt. imaginer avoir un contrôle de ce type. Mais encore une fois les règles business sont dans les services qui manipulent les objets et non dans les objets eux même à mon sens.

    Citation Envoyé par dad3zero Voir le message
    Donc, si j'ai un composant qui fait quelque chose avec des employés, je devrai dupliquer du code pour rendre en compte 2 types différents présentant 2 méthodes différentes et donc avoir une connaissance concrète de ce qu'il y a derrière ? N'est ce pas lourd en maintenance ?

    Et sinon, que contient getEmployees comme code (en supposant les éléments stockés dans un attribut type ArrayList ?
    Heu non tu ne duplique rien car tu ne manipules pas les même objets. Dans un cas c'est un DAO (Repository) via findAll() et dans l'autre c'est un POJO via getEmployes(), une entité ou je ne sais quoi (l'objet BU ). Ces 2 types d'objets n'ont rien en commun, ne seront pas exploités au même endroit de l'application et la sémantique des méthodes est différentes.

    Le traitement suite à la récupération des employés reste identique car dans tous les cas tu reçoit une liste d'employés

  14. #114
    Membre habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 47
    Points : 148
    Points
    148

    Par défaut

    Ok merci, je vois. C'est en effet inutile de parler concepts de base à ce niveau.

  15. #115
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2017
    Messages : 80
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    Ok merci, je vois. C'est en effet inutile de parler concepts de base à ce niveau.
    ... Je ne sais pas trop comment prendre cette remarque... Elle sent fort le dénigrement mais j’espère me tromper.

  16. #116
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    (tout ce débat parce-que le béotien en objet que je suis n'a pas été précis dans sa distinction getter-propriété - désolé les gars - mais j'apprends pas mal de trucs en vous lisant)
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  17. #117
    Membre expert Avatar de yildiz-online
    Homme Profil pro
    Architecte logiciel
    Inscrit en
    octobre 2011
    Messages
    1 078
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte logiciel

    Informations forums :
    Inscription : octobre 2011
    Messages : 1 078
    Points : 3 509
    Points
    3 509

    Par défaut

    Dans tous les cas, les getter/setter sont à éviter au maximum en orienté objet, ils vont à l'encontre de l'encapsulation en exposant le contenu de l'objet plutôt que son comportement, de la loi de Déméter (avec les get chainés qu'on voit bien souvent), et sont à la base de l'anti-pattern des classes anémiques.

    On leur préférera des objets du domaine qui exposent un comportement manipulant leur données interne pour matérialiser la logique métier pour une architecture domain driven(Une exception bien sûr avec les objets de transfert de données), ou des objets léger mais immuables pour de l'event driven.
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  18. #118
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2015
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bas Rhin (Alsace)

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

    Informations forums :
    Inscription : mars 2015
    Messages : 1 105
    Points : 2 632
    Points
    2 632

    Par défaut

    Citation Envoyé par yildiz-online Voir le message
    Dans tous les cas, les getter/setter sont à éviter au maximum en orienté objet, ils vont à l'encontre de l'encapsulation en exposant le contenu de l'objet plutôt que son comportement, de la loi de Déméter (avec les get chainés qu'on voit bien souvent), et sont à la base de l'anti-pattern des classes anémiques.

    On leur préférera des objets du domaine qui exposent un comportement manipulant leur données interne pour matérialiser la logique métier pour une architecture domain driven(Une exception bien sûr avec les objets de transfert de données), ou des objets léger mais immuables pour de l'event driven.
    Désolé, mais je n'ai absolument rien compris du début jusqu'à la fin. En quoi les getter/setter vont à l'encontre du principe d'encapsulation alors qu'ils sont précisément une implémentation de se principe, comme les properties de C# ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  19. #119
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Citation Envoyé par Grogro Voir le message
    En quoi les getter/setter vont à l'encontre du principe d'encapsulation alors qu'ils sont précisément une implémentation de se principe, comme les properties de C# ?
    L'un des buts de l'encapsulation est de pouvoir changer facilement l'implémentation sans changer l'interface. Or, les accesseurs (alias getters) et les mutateurs (alias setters) imposent des contraintes fortes sur l'interface qui peuvent empêcher de changer facilement l'implémentation.

    J'ai donné un exemple dans mon message du 20/09/2018 à 16h18.
    On pourrait construire un exemple similaire avec une classe qui interagit avec une base de données ou une classe qui permet d'envoyer des courriels.

  20. #120
    Membre expert Avatar de yildiz-online
    Homme Profil pro
    Architecte logiciel
    Inscrit en
    octobre 2011
    Messages
    1 078
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte logiciel

    Informations forums :
    Inscription : octobre 2011
    Messages : 1 078
    Points : 3 509
    Points
    3 509

    Par défaut

    Citation Envoyé par Grogro Voir le message
    En quoi les getter/setter vont à l'encontre du principe d'encapsulation alors qu'ils sont précisément une implémentation de se principe
    Tout d'abord, parce qu'il permettent de connaître la composition interne d'une classe, qui de ce fait n'est absolument plus une boite noire, et parce qu'ils permettent de modifier cette composition, directement (via les setter) ou indirectement (via les getter sur des objets mutables).

    Pour faire une analogie, c'est comme si on prêtait sa voiture à un mécano, qui pourrait s'amuser à regarder sous le capot et changer des pièces du moteur, alors qu'on voudrait un simple conducteur dont la compétence sur la voiture est de mettre le contact et tourner le volant.
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

+ Répondre à la discussion
Cette discussion est résolue.
Page 6 sur 7 PremièrePremière ... 234567 DernièreDernière

Discussions similaires

  1. changer le langage sur excel
    Par kaquelle dans le forum Excel
    Réponses: 4
    Dernier message: 06/04/2011, 12h30
  2. Changer de langage, vos avis sur ce cas ?
    Par bewidia dans le forum Langages de programmation
    Réponses: 0
    Dernier message: 30/10/2009, 18h39
  3. Java modifié sera-t-il le langage de référence et le meilleur ?
    Par Orvinfait dans le forum Général Java
    Réponses: 7
    Dernier message: 04/10/2009, 23h01
  4. Changer le langage utilisé pour le projet
    Par Thierry Chappuis dans le forum Code::Blocks
    Réponses: 4
    Dernier message: 23/04/2007, 13h23
  5. Changer de langage, mais pour lequel ?
    Par reptils dans le forum Langages de programmation
    Réponses: 5
    Dernier message: 02/02/2006, 17h01

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