Discussion :

[GordonFreeman]

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.

Voilà une explication claire, précise et concise du principe et du contexte, félicitations.
Mais effectivement il faut voir ou l'on se situe, objets de domaine, POJO / DTO, entités... Je pense que la conception et la réflexions sur ces différents types d'objets ne sera pas forcément la même.
On arrive dans des réflexions un peu plus avancée que les principes de base de la POO.

L'architecture de l'appli joue également un rôle... il n'est pas toujours possible de faire du DDD, ce qui n'empêche pas de faire une structure applicative propre.

Encore une fois lorsqu'on discute de concept informatique, je pense qu'il est bon de préciser le contexte. Chose que tu as très bien fait dans ton post yildiz-online
Effectivement tu avais également très bien décris la problématique dans ton post Pyramidev

[Grogro]

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.

Je ne comprends absolument pas comment tu es supposé interagir avec l'instance d'une classe, si une bonne pratique (dont je n'ai jamais entendu parler en 4 ans d'expérience sur plusieurs projets) serait de se passer de getters et de setters publics.

Donc... tous les attributs d'une classe sont non seulement privés (jusque là ok, c'est la base de l'encapsulation que tout le monde utilise), mais les getters et les setters visibles et manipulables de l'extérieur seraient à remplacer par des méthodes publiques, éventuellement incorporant une logique métier ? Pour moi ce n'est pas le but des objets métiers qui sont de simples POJOs, sérialisables au besoin. Je suis peut-être atteint du syndrome du "golden hammer", mais pour moi la logique métier, c'est le rôle de la couche service.

Je dis pas que j'ai vu du code propre, loin de là, mais ce que tu dis va à l'encontre de tout ce que j'ai vu en entreprise.

Ou alors c'est une toute autre conception d'architecture logicielle que je ne connais pas et que je dois donc apprendre.

Edit : je précise que je ne suis plus développeur mais ingénieur QA.

[yildiz-online]

Je ne comprends absolument pas comment tu es supposé interagir avec l'instance d'une classe, si une bonne pratique (dont je n'ai jamais entendu parler en 4 ans d'expérience sur plusieurs projets) serait de se passer de getters et de setters publics.

En manipulant son comportement exposé, plutôt que ses données.
Par exemple tu aurais une méthode myIncredibleAudioSystem.increaseVolume(x) plutot que myIncredibleAudioSystem.getVolume().setValue(currentVolume + x)

Donc... tous les attributs d'une classe sont non seulement privés (jusque là ok, c'est la base de l'encapsulation que tout le monde utilise), mais les getters et les setters visibles et manipulables de l'extérieur seraient à remplacer par des méthodes publiques, éventuellement incorporant une logique métier ? Pour moi ce n'est pas le but des objets métiers qui sont de simples POJOs, sérialisables au besoin. Je suis peut-être atteint du syndrome du "golden hammer", mais pour moi la logique métier, c'est le rôle de la couche service.

Un pojo est peut-être un objet métier, mais ce n'est pas un objet contenant du métier, il souffre de l'anti-pattern objet anémique, et donc à besoin d'autres objets pour réaliser un comportement.

Je dis pas que j'ai vu du code propre, loin de là, mais ce que tu dis va à l'encontre de tout ce que j'ai vu en entreprise.

Effectivement, et c'est regrettable, les architecture en couche sont ne sont pas optimale en terme de déploiement, d'extensibilité horizontale, de performance et d'agilité.
Mais elle sont les plus simples à mettre en oeuvre, sont facilement testables, c'est pourquoi ce sont celle qu'on retrouvera le plus souvent.
Elle ont tout leur intéret sur des application simples de type CRUD, mais dès que ça se complexifie, d'autres approches sont plus intéressantes.

Ou alors c'est une toute autre conception d'architecture logicielle que je ne connais pas et que je dois donc apprendre.

Le DDD n'est pas une architecture en tant que tel, c'est une approche(qui peut être concrétisée par une architecture hexagonale)

Edit : je précise que je ne suis plus développeur mais ingénieur QA.

Je ne suis plus développeur non plus, professionnellement du moins.

[dad3zero]

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

Olà mais oui, il y avait une vrai question en fait, celle du 18, c'est ça

Ta notion "d'accesseurs" (et pourquoi pas de mutateur également) riches est exactement ce que doivent être les interfaces des objets. En fait, c'est justement ces possibilités qu'offrent les Properties/Attributs calculés de manière plus naturelle. Exemple : si on veut modéliser le comportement simplifié d'une cocotte-minute, on peut appliquer l'équation des gaz parfaits à savoir PV = nRT. On peut faire un modèle objet où n (quantité de gaz), V (volume), P (pression) et T (température) sont des attributs. Allez, on simplifie avec V, n et R (constante) constants (futé pour R…), V et n sont fixés. T est accessible (thermomètre) et modifiable (on chauffe ou on coupe le chauffage). Mais la pression… Une cocotte n'a pas forcément de manomètre. Pourtant, on pourra modéliser un objet Cocotte avec des attributs V, n et T qui auront une valeur réelle, mais aussi un attribut P qui retournera le résultat nRT/V. Ceci est donc totalement transparent pour celui qui manipule cet objet. De même, on pourra déclarer que l'affectation d'une valeur à P signifie en fait modifier T de telle manière à ce que T soit égale à PV/nR.

De même, si on parle réellement d'Objets au sens POO, un "setter" se doit d'être garant de la cohérence d'une donnée, donc par exemple, pas de volume négatif…

Mais tu parlais aussi de perf et là aussi ça peut être intéressant puisque lorsque tu aura déterminé que ça coince, tu peux faire évoluer l'objet en ajoutant un cache dans la méthode d'accès. C'est ce que permet le principe de l'encapsulation : peu importe comment c'est implanté, l'important est de fournir le job et surtout de faire évoluer le composant pour fournir le job le plus adapté sans modifier l'existant.

Alors le fait est qu'il y a un point sur lequel tu a raison, c'est la "qualité du développeur". Et je vais m'attirer des pouces négatifs, mais Java est l'exemple type du langage qui a accumulé des horreurs de conception conduisant à la performance d'utiliser un langage objet sans mise en œuvre du paradigme POO… Pour moi, ça a été exacerbé par une certaine littérature qui a bien incité à rester sur une approche procédurale du code.

[dad3zero]

Je ne comprends absolument pas comment tu es supposé interagir avec l'instance d'une classe, si une bonne pratique (dont je n'ai jamais entendu parler en 4 ans d'expérience sur plusieurs projets) serait de se passer de getters et de setters publics.

Le problème est que tout dépend dans quel contexte tu a vu passer ces "bonnes pratiques". Et d'un point de vu personnel pour moi, qui ai une bonne expérience dans le domaine Java "plateau de devs", c'est caractéristique de ceux qui n'ont rien compris à l'Objet et qui font du pur procédural.

Donc... tous les attributs d'une classe sont non seulement privés (jusque là ok, c'est la base de l'encapsulation que tout le monde utilise)

Non, ça c'est la base de la pratique Java. Pour une approche Objet, un attribut est public ou privé. Mais, des langages peuvent nécessiter des contraintes, ainsi oui, en Java les attributs seront privés et manipulés par des accesseurs/mutateurs mais dans des langages comme Python ou Swift (et probablement C# à ce que je lis mais ne connais pas), indifféremment public ou privé en fonction du besoin. C'est ainsi que sera appliqué le principe de l'accès uniforme.

Pour moi ce n'est pas le but des objets métiers qui sont de simples POJOs

C'est quoi un "simple POJO" ? Car tel que défini par Martin Fowler et Josh MacKenzie en 2000, il s'agit d'opposer ces objets aux EJBs afin de gérer la logique métier de manière indépendante d'un Framework. C'est tout. Après c'est parti en sucette lorsque la définition est devenue "un objet qui a un constructeur vide, des attributs privés et que des getters/setters pour ces attributs qui ne font rien d'autre qu'attribuer une valeur et la fournir". Cela aurai pu se simplifier par des objets avec un constructeur vide et des attributs publiques mais bon… Bref, une struct n'est pas un objet. Si on souhaite mettre en œuvre le paradigme Orienté Objet, les objets métier incorporent la logique métier (directement ou indirectement). Dans une approche procédurale comme le C, on manipule ses données dans des structs à l'aide de bibliothèques de fonctions.

Je dis pas que j'ai vu du code propre, loin de là, mais ce que tu dis va à l'encontre de tout ce que j'ai vu en entreprise.

Je pense que j'ai suffisamment laissé entendre que ce n'est pas parce que c'est vu en entreprise que c'est "propre". En entreprise, on est plus "Programmation Orientée Hip"…

Ou alors c'est une toute autre conception d'architecture logicielle que je ne connais pas

La Programmation Orientée Objet, tout simplement…*Je peux conseiller le Meyer comme bonne base.

[el_slapper]

Ta notion "d'accesseurs" (et pourquoi pas de mutateur également) riches est exactement ce que doivent être les interfaces des objets. (.../...)

En fait, tout ça, j'ai tendance à le mettre dans des setters-getters. Je me rends compte que finalement, je fais presque ce que tu dis(avec certainement moins de maitrise théorique), et j'ai mis parfois des getters ou setters sans équivalent en local, juste pour accéder à une données calculée, ou pour retravailler une donnée en entrée. J'aurais du faire des propriétés/méthodes, si je te lis bien.

Mais tu parlais aussi de perf et là aussi ça peut être intéressant puisque lorsque tu aura déterminé que ça coince, tu peux faire évoluer l'objet en ajoutant un cache dans la méthode d'accès. C'est ce que permet le principe de l'encapsulation : peu importe comment c'est implanté, l'important est de fournir le job et surtout de faire évoluer le composant pour fournir le job le plus adapté sans modifier l'existant.

Oui, mais ce n'est clairement pas la manière dont les gens travaillent, pour la plupart. Toi, moi, sommes assez bons pour faire ça(et toi sans doute encore plus que moi). Le développeur moyen, c'est au delà de ses capacités.

Alors le fait est qu'il y a un point sur lequel tu a raison, c'est la "qualité du développeur". Et je vais m'attirer des pouces négatifs, mais Java est l'exemple type du langage qui a accumulé des horreurs de conception conduisant à la performance d'utiliser un langage objet sans mise en œuvre du paradigme POO… Pour moi, ça a été exacerbé par une certaine littérature qui a bien incité à rester sur une approche procédurale du code.

Le VBA EXCEL aussi. C'est un langage que j'ai beaucoup utilisé, qui est bien plus puissant et bien plus propre que sa réputation ne le laisse entendre(même si la couche objet n'est hélas qu'une surcouche, et que ça reste un outil pour travailler seul, pas en équipe), quand on creuse un peu. Mais qui est le plus souvent utilisé par des gens pas plus doués, et en plus biens moins formés, que les Javaistes que tu dénonces.[/QUOTE]

Le problème est que tout dépend dans quel contexte tu a vu passer ces "bonnes pratiques". Et d'un point de vu personnel pour moi, qui ai une bonne expérience dans le domaine Java "plateau de devs", c'est caractéristique de ceux qui n'ont rien compris à l'Objet et qui font du pur procédural.

D'ou la fluidité de notions de "bonnes pratiques". Si tu sais par expérience que tu n'as pas les moyens d'attirer les gens qui feront du code propre, le bon vieux procédural n'est pas si idiot que ça. Parceque ça marchera quand même. Mal, à fort cout, mais ça marchera. Un bel objet inaccessible au commun des mortels, ça peut être superpuissants entre les bonnes mains, et catastrophiques dans des mains moins douées. Les "bonnes pratiques" en entreprises visent souvent à rendre le code plus accessible à des gens moyens, pas à l'optimiser magnifiquement. Un exemple vécu. En Cobol, certes, mais quand même. Certaines maisons ont des bonnes pratiquent qui bannissent le GO TO, sauf pour une gestion d'erreur qui fasse :

IF ERROR-TRUE
GO TO END-PARAGRAPH
END-IF

Tout ça pour supprimer un niveau d'indentation et rendre le code plus lisible pour des gens qui auraient du mal. Complètement inutile pour des gens de haut niveau, mais fait pour les autres. (on notera que j'utilise une encapsulation du message d'erreur par booléen (on appelle ça un niveau 88), un truc très rudimentaire par rapport à une propriété en objet, mais qui permet quand même d'éviter un mochissime IF ERRCODE LESSER THAN ZERO, qui présume sur ce qu'est un code erreur qui plante ou pas)

Dans une maison ou on sait qu'on a que des bons, on peut se permettre d'aller plus loin que ça, évidemment.

[Grogro]

La Programmation Orientée Objet, tout simplement…*Je peux conseiller le Meyer comme bonne base.

Celui-là : https://www.eyrolles.com/Informatiqu...-9782212675009 ?

Merci pour vos réponses, on en apprend beaucoup.

[RegBas]

désolé du déterrage mais .... pourquoi dans ce pseudo débat Property vs getter / setter vous partez du principe que ces derniers sont forcément et systématiquement publics ?
Vu comme ça c'est sur qu'un POJO devient en effet l'équivalent d'un struct oui ... ou qu'encore un mauvais Dev mettrait dans une interface son getLegacyLogger salement .... mais pourquoi ce meme gars mettrait pas sa property LegacyLogger en public de la même façon ?

J'ai l'impression que tout le débat se repose sur des exemples du type un mauvais dév JAVA vs un bon dév C# (je ne connais que les property de C# ... qui sont clairement un sucre ... appréciable mais un sucre)

Etant dans un environnement de travail avec précisément ces 2 langages, ca m'interesserait si vous aviez d'autres arguments /exemples, au cas où j'ai vraiment raté un wagon ....

[dad3zero]

désolé du déterrage mais .... pourquoi dans ce pseudo débat Property vs getter / setter vous partez du principe que ces derniers sont forcément et systématiquement publics ?

Parce qu'un getter/setter privé n'a aucun sens…

(je ne connais que les property de C# ... qui sont clairement un sucre ... appréciable mais un sucre)

Je ne connais pas les property du C# mais les équivalents en Python ou Swift ne sont du "sucre" mais bien un outil qui permet de faire de la POO et non du procédural.

[RegBas]

Parce qu'un getter/setter privé n'a aucun sens…
Je ne connais pas les property du C# mais les équivalents en Python ou Swift ne sont du "sucre" mais bien un outil qui permet de faire de la POO et non du procédural.

Donc tes property sont systématiquement publiques ? Ah oui en Python oui forcément. Je ne connais pas Swift, mais je comprends mieux. Les getter / setter en JAVA permettent de gérer l'encapsulation, mais du coup on ne peut pas en parler en faisant abstraction ou en connaissant mal la gestion des niveaux d'accès qui n'existe pas en Python (il y a des conventions de nommage mais bon ....). Et si des getters ou setters privés n'ont pas de sens pour toi, c'est qu'effectivement tu est très très peu familier de ces concepts de niveaux d'accès.

Edit : En fait, de la même façon qu'il est mal de faire du "procédural" dans un langage POO, c'est aussi mal d'écrire du JAVA comme si c'était du Python ... dans les 2 cas le pb n'est pas le langage mais le gars qui tape au clavier.

[el_slapper]

(.../...)Edit : En fait, de la même façon qu'il est mal de faire du "procédural" dans un langage POO, c'est aussi mal d'écrire du JAVA comme si c'était du Python ... dans les 2 cas le pb n'est pas le langage mais le gars qui tape au clavier.

Ou d'écrire en COBOL comme si c'était du C, de l'assembleur, ou du JAVA(vécu, c'était immonde). Pour moi, c'est la plus grande difficulté de passer d'un langage à un autre - assimiler la culture sous-jacente. Parceque bon, on peut passer entre tous ces langages facilement, et avec un peu de talent, faire marcher ce qu'on a à faire marcher. Le faire de manière propre et maintenable par la communauté, c'est une autre paire de manches. Je me souviens avoir un jour émis des doutes sur la maintenabilité du LISP, et on m'avait répondu "en fait, pas du tout - ils ont tous eu les mêmes profs, et programment tous de la même manière, donc le code LISP est en fait très maintenable". J'ignore si c'est vrai ou faux, mais c'est un argument qui porte - sauf si moi avec mes réflexes, euh, différents, je me mets à faire du LISP.

Je n'ai aucun doute sur ma capacité à faire du LISP qui marche et que je puisse maintenir. En faire qui soit maintenable par la communauté, euh, une toute autre paire de manches. Pareil pour JAVA, Python, etc.....

[Pyramidev]

ils ont tous eu les mêmes profs, et programment tous de la même manière

« tous eu les mêmes profs » ? Je sais que les développeurs Lisp ne sont pas nombreux, mais quand même !
« programment tous de la même manière » ? S'ils ont compris la puissance des dialectes du Lisp, j'en doute fort.

Je suis en train de lire On Lisp de Paul Graham à propos de Common Lisp. J'en ai déjà lu un peu plus du tiers et Paul Graham définit plein de macros pour étendre la syntaxe du langage. En terme de maintenabilité, le gros avantage, c'est que cela permet de pousser loin la réutilisabilité du code. Au lieu de réécrire le même code verbeux qui favorise les erreurs d'étourderies, on écrit du code plus concis en réutilisant des constructions déjà optimisées et déjà testées. Le prix à payer est que, si un nouveau développeur se joint au projet, il doit apprendre les constructions existantes.

À propos de la difficulté de lire ce type de code, Paul Graham affirme ceci à la page 59 :

If your code uses a lot of new utilities, some readers may complain that it is hard to understand. People who are not yet very fluent in Lisp will only be used to reading raw Lisp. In fact, they may not be used to the idea of an extensible language at all. When they look at a program which depends heavily on utilities, it may seem to them that the author has, out of pure eccentricity, decided to write the program in some sort of private language.
[...]
So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.
If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn’t do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay.

Il exagère un peu, mais c'est en partie vrai.

[dad3zero]

Donc tes property sont systématiquement publiques ? Ah oui en Python oui forcément. Je ne connais pas Swift, mais je comprends mieux. Les getter / setter en JAVA permettent de gérer l'encapsulation, mais du coup on ne peut pas en parler en faisant abstraction ou en connaissant mal la gestion des niveaux d'accès qui n'existe pas en Python (il y a des conventions de nommage mais bon ....). Et si des getters ou setters privés n'ont pas de sens pour toi, c'est qu'effectivement tu est très très peu familier de ces concepts de niveaux d'accès.

Edit : En fait, de la même façon qu'il est mal de faire du "procédural" dans un langage POO, c'est aussi mal d'écrire du JAVA comme si c'était du Python ... dans les 2 cas le pb n'est pas le langage mais le gars qui tape au clavier.

Bien sûr que les properties sont publiques, pour un accès privé, on accède directement aux attributs.

Nope, un getter/setter ne permet pas de gérer l'encapsulation mais la visibilité, l'encapsulation est gérée par ce que tu déclare publique et privé. Pire, l'usage des getters/setters tel qu'il est actuellement en Java, amplifié par des frameworks comme Spring, vont au contraire à l'encontre de l'encapsulation (dans la pratique ils exposent l'implémentation). Cela n'a aucun rapport avec le niveau d'accès.

[dad3zero]

Ou d'écrire en COBOL comme si c'était du C, de l'assembleur, ou du JAVA(vécu, c'était immonde). Pour moi, c'est la plus grande difficulté de passer d'un langage à un autre - assimiler la culture sous-jacente. Parceque bon, on peut passer entre tous ces langages facilement, et avec un peu de talent, faire marcher ce qu'on a à faire marcher. Le faire de manière propre et maintenable par la communauté, c'est une autre paire de manches.

C'est ce sur quoi j'insiste le plus en formation : apprendre un nouveau langage ne consiste pas juste à apprendre une syntaxe pour faire une transposition mais également les idiomes de ce langage. RegBas a tout à fait raison : on n'écrit pas du Python comme on écrit du Java. Sur la structure d'une part, mais aussi sur certains outils propres au langage (comme éviter les exceptions en Java, en abuser en Python). Par contre, on doit retrouver les principes des paradigmes.

[dad3zero]

À propos de la difficulté de lire ce type de code, Paul Graham affirme ceci à la page 59 :

Il exagère un peu, mais c'est en partie vrai.

Merci pour la citation car j'ai toujours la difficulté de la question de l'équilibre entre mise en œuvre experte des technos et accessibilité… Il y a de l'argument.

[RegBas]

Bien sûr que les properties sont publiques

En python oui, parce qu'il n'y a pas de (vraie) notion de niveau d'accès.

Nope, un getter/setter ne permet pas de gérer l'encapsulation mais la visibilité, l'encapsulation est gérée par ce que tu déclare publique et privé.

Pas de setter ou setter privé (si, si, ça a un sens) ? Encore une fois, séparer les 2 parce que les niveaux d'accès n'existent pas en Python est une mauvaise façon de comparer les approches des 2 languages.

Pire, l'usage des getters/setters tel qu'il est actuellement en Java, amplifié par des frameworks comme Spring, vont au contraire à l'encontre de l'encapsulation (dans la pratique ils exposent l'implémentation).

Oui, la reflexion peut casser l'encapsulation .... c'est le principe. Mais ça n'est qu'un framework. Alors c'est sûr que comparé à C# par exemple, l'injection de dépendance en Java peut sembler mmh ... laborieuse.
Python résoud cela en ayant tout accessible de base, et repose encore plus fortement sur les bonnes pratiques du développeur par exemple (pas besoin d'un framework ou autre pour écrire objA._attributB = x de partout, en court-circuitant toute property définie sur cet attribut ...
On peut préférer l'une ou l'autre des approches mais face à de mauvais dév, le pire sera fait dans les 2 cas.

Quant à exposer l'implémentation et aller à l'encontre de l'encapsulation, oui, si on écrit comme un robot des getters/setters de façon systématique TOUS publics pour TOUS les membres de sa classe ... ce que tu semble croire être l'usage courant/mis en avant/la bonne pratique en Java ... ? Je te rassure ça ne l'est pas.

[dad3zero]

En python oui, parce qu'il n'y a pas de (vraie) notion de niveau d'accès.

Mais… je ne parle pas de Python… En POO, c'est tout…

Pas de setter ou setter privé (si, si, ça a un sens) ? Encore une fois, séparer les 2 parce que les niveaux d'accès n'existent pas en Python est une mauvaise façon de comparer les approches des 2 languages.[/qoute]

À part d'être payé à la ligne de code ou au cycle exécuté, non. Pour un accès interne, vous utilisez les attributs, ou une méthode. À nouveau, je ne sais pas pourquoi vous parlez de Python, ça n'a rien à voir.

[quote)Oui, la reflexion peut casser l'encapsulation .... c'est le principe. Mais ça n'est qu'un framework. Alors c'est sûr que comparé à C# par exemple, l'injection de dépendance en Java peut sembler mmh ... laborieuse.
Python résoud cela en ayant tout accessible de base, et repose encore plus fortement sur les bonnes pratiques du développeur par exemple (pas besoin d'un framework ou autre pour écrire objA._attributB = x de partout, en court-circuitant toute property définie sur cet attribut ...
On peut préférer l'une ou l'autre des approches mais face à de mauvais dév, le pire sera fait dans les 2 cas.

Mais…*Non plus…*La réflexion ne consiste pas à "casser l'encapsulation", l'encapsulation est un contrat de comportement. Si l'intercission consiste à modifier son état d'exécution, elle doit être mise en œuvre en s'assurant de la fiabilité de comportement.

Quant à exposer l'implémentation et aller à l'encontre de l'encapsulation, oui, si on écrit comme un robot des getters/setters de façon systématique TOUS publics pour TOUS les membres de sa classe ... ce que tu semble croire être l'usage courant/mis en avant/la bonne pratique en Java ... ? Je te rassure ça ne l'est pas.

Ça rassurerait peut être, mais ça voudrait dire qu'après plus de 10 ans de pratique telle que je la connais, elle aurait changé ces 6 derniers mois…

[Mat.M]

ou bien faut-il envisager de changer de langage ?

désolé si cela a été écrit précédemment mais changer de langage c'est très coûteux pour une entreprise.
Pour un projet perso c'est pas trop grave mais pour un projet logiciel d'entreprise eh bien il faut transformer des milliers de lignes de code d'un langage vers un autre.
je suis bien placé pour le savoir car j'ai effectué la migration d'un logiciel pour l'immobilier de VB6 vers VB.Net cela a pris plus d'un an et demi.

Et puis le problème d'un changement de langage donc de technologie c'est qu'on ne peut pas toujours capitaliser sur les développements antérieurs puisqu'il faut tout refaire

[vertex.3F]

Normalement , ta source écrite en Java 1.2 , est comprise par le compileur Java 10 . Il faut juste la mettre au gout du jour du fait des fonctionnalités apparu entre temps

non hélas, et c'est plutot facile de savoir pourquoi (une simple requete dans un moteur de recherche Internet)





Compatibility Guide for JDK 8 https://www.oracle.com/technetwork/j...e-2156366.html et plus précisément https://www.oracle.com/technetwork/j...6.html#A999387

Incompatibilities between Java SE 8 and Java SE 7

Java SE 8 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 8 without modification. However, there are some minor potential incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness.

This section describes Java SE 8 incompatibilities in the Java Language, the JVM, or the Java SE API.

Note that some APIs have been deprecated in this release and some features have been removed entirely. While these are incompatibilities, they have been called out in separate lists. For more information, see Deprecated APIs and Features Removed from JDK 8.

A Maintenance Release of Java SE 8 was performed in March 2015. Incompatibilities arising out of this release are marked accordingly.

How and When To Deprecate APIs https://docs.oracle.com/javase/7/doc...precation.html

What "Deprecated" Means

You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.

Java provides a way to express deprecation because, as a class evolves, its API (application programming interface) inevitably changes: methods are renamed for consistency, new and better methods are added, and fields change. But such changes introduce a problem. You need to keep the old API around until developers make the transition to the new one, but you don't want them to continue programming to the old API.

The ability to deprecate a class, method, or member field solves the problem. Java supports two mechanisms for deprecation: and an annotation, (supported starting with J2SE 5.0) and a Javadoc tag (supported since 1.1). Existing calls to the old API continue to work, but the annotation causes the compiler to issue a warning when it finds references to deprecated program elements. The Javadoc tag and associated comments warn users against using the deprecated item and tell them what to use instead.

When to Deprecate

When you design an API, carefully consider whether it supersedes an old API. If it does, and you wish to encourage developers (users of the API) to migrate to the new API, then deprecate the old API. Valid reasons to deprecate an API include:

• It is insecure, buggy, or highly inefficient
• It is going away in a future release
• It encourages bad coding practices

Deprecation is a reasonable choice in all these cases because it preserves "backward compatibility" while encouraging developers to change to the new API. Also, the deprecation comments help developers decide when to move to the new API, and so should briefly mention the technical reasons for deprecation.

It is not necessary to deprecate individual member fields (properties) of a deprecated class, unless of course you want to explain a specific point about a property.

il n'y a pas que Java et ses API qui sont concernés par les fonctionnalités dépréciées et autres discontinuités des langages

• https://secure.php.net/manual/fr/mig...compatible.php ou http://php.net/manual/fr/migration70.php
• https://docs.microsoft.com/fr-fr/dot...whats-obsolete
• https://blog.invivoo.com/la-migratio...-a-python-3-x/

[openlowcode]

Bonjour,
Du coup, je me pose, sérieusement, la question : faut-il faire ces changements, prévoir d'en faire d'autres dans le futur, et caler sa roadmap sur celle de Java -- avec un décalage -- ou bien faut-il envisager de changer de langage ?

J'ai l'impression que l'on peut rester sur java en faisant utilsant OpenJDK et les autres versions / outils Open source de java. En fait, ce qui est payant, c'est le "choix par défaut" de la JVM Oracle, mais il existe d'autres possibilités.