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. #121
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    82
    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 : 82
    Points : 442
    Points
    442

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

  2. #122
    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 : 33
    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 584
    Points
    2 584

    Par défaut

    Citation Envoyé par yildiz-online Voir le message
    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.
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  3. #123
    Expert confirmé Avatar de yildiz-online
    Homme Profil pro
    Architecte logiciel
    Inscrit en
    octobre 2011
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte logiciel

    Informations forums :
    Inscription : octobre 2011
    Messages : 1 219
    Points : 4 081
    Points
    4 081

    Par défaut

    Citation Envoyé par Grogro Voir le message
    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)

    Citation Envoyé par Grogro Voir le message
    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.

    Citation Envoyé par Grogro Voir le message
    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.

    Citation Envoyé par Grogro Voir le message
    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)

    Citation Envoyé par Grogro Voir le message
    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.
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  4. #124
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    (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.

  5. #125
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par Grogro Voir le message
    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.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 742
    Points : 26 072
    Points
    26 072

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    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.

    Citation Envoyé par dad3zero Voir le message
    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.

    Citation Envoyé par dad3zero Voir le message
    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]

    Citation Envoyé par dad3zero Voir le message
    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.
    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.

  7. #127
    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 : 33
    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 584
    Points
    2 584

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    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.
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  8. #128
    Membre du Club
    Profil pro
    Inscrit en
    août 2002
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 38
    Points : 69
    Points
    69

    Par défaut

    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 ....
    Il y a toujours une solution

  9. #129
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par RegBas Voir le message
    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.

  10. #130
    Membre du Club
    Profil pro
    Inscrit en
    août 2002
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 38
    Points : 69
    Points
    69

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    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.
    Il y a toujours une solution

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 742
    Points : 26 072
    Points
    26 072

    Par défaut

    Citation Envoyé par RegBas Voir le message
    (.../...)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.....
    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.

  12. #132
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    944
    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 : 944
    Points : 4 057
    Points
    4 057

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.

  13. #133
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par RegBas Voir le message
    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.

  14. #134
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.

  15. #135
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par Pyramidev Voir le message

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

  16. #136
    Membre du Club
    Profil pro
    Inscrit en
    août 2002
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 38
    Points : 69
    Points
    69

    Par défaut

    Citation Envoyé par dad3zero Voir le message
    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.

    Citation Envoyé par dad3zero Voir le message
    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.

    Citation Envoyé par dad3zero Voir le message
    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.
    Il y a toujours une solution

  17. #137
    Membre actif
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    73
    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 : 73
    Points : 228
    Points
    228

    Par défaut

    Citation Envoyé par RegBas Voir le message
    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…

  18. #138
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 819
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 819
    Points : 14 267
    Points
    14 267

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    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
    Ce dont on ne peut parler il faut le taire ( Wittgenstein )

  19. #139
    Membre averti

    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2013
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2013
    Messages : 63
    Points : 409
    Points
    409

    Par défaut

    Citation Envoyé par darklinux Voir le message
    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


  20. #140
    Membre du Club Avatar de openlowcode
    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2019
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2019
    Messages : 33
    Points : 65
    Points
    65

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    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.
    Open Lowcode Applications sur mesure, résultats rapides et à coûts réduits (repo Github)

+ Répondre à la discussion
Cette discussion est résolue.
Page 7 sur 8 PremièrePremière ... 345678 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, 11h30
  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, 17h39
  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, 22h01
  4. Changer le langage utilisé pour le projet
    Par Thierry Chappuis dans le forum Code::Blocks
    Réponses: 4
    Dernier message: 23/04/2007, 12h23
  5. Changer de langage, mais pour lequel ?
    Par reptils dans le forum Langages de programmation
    Réponses: 5
    Dernier message: 02/02/2006, 16h01

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