Discussion :

[GordonFreeman]

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;

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

[dad3zero]

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.

[GordonFreeman]

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

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.

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 ?

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

[dad3zero]

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…

[GordonFreeman]

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

[Pyramidev]

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.

[GordonFreeman]

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

[dad3zero]

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.

[deltree]

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)

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.

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.

[GordonFreeman]

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.

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 ?

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

[GordonFreeman]

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

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

[dad3zero]

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 ?

[GordonFreeman]

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.

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

[dad3zero]

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

[GordonFreeman]

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.

[el_slapper]

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

[yildiz-online]

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.

[Grogro]

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# ?

[Pyramidev]

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.

[yildiz-online]

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.