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
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

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

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

    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 582
    Points
    2 582

    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
    Membre expert Avatar de yildiz-online
    Homme Profil pro
    Architecte logiciel
    Inscrit en
    octobre 2011
    Messages
    1 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte logiciel

    Informations forums :
    Inscription : octobre 2011
    Messages : 1 129
    Points : 3 713
    Points
    3 713

    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 483
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 483
    Points : 24 457
    Points
    24 457

    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 582
    Points
    2 582

    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 483
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 483
    Points : 24 457
    Points
    24 457

    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
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    844
    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 : 844
    Points : 3 655
    Points
    3 655

    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 762
    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 762
    Points : 14 042
    Points
    14 042

    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 )

+ Répondre à la discussion
Cette discussion est résolue.
Page 7 sur 7 PremièrePremière ... 34567

Discussions similaires

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

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo