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 : 409
    Points
    409

    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 : 32
    Localisation : France, Bas Rhin (Alsace)

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

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

    Par défaut

    Citation Envoyé par yildiz-online Voir le message
    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 078
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte logiciel

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

    Par défaut

    Citation Envoyé par Grogro Voir le message
    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 habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

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

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

    Par défaut

    Citation Envoyé par 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 habitué
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2018
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

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

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

    Par défaut

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 377
    Points : 23 817
    Points
    23 817

    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 : 32
    Localisation : France, Bas Rhin (Alsace)

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

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

    Par défaut

    Citation Envoyé par 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

+ 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