• [^] # Re: Chacun son style

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.

    Donc, vas-y, donne nous ta version de code qui fait la même chose en respectant la fameuse loi.

    Le soucis est que tu veux faire quelque chose d'aberrant (contrôler le rendu graphique depuis n'importe quel point de l'application). Ça posera beaucoup de problèmes d'interdépendance des différentes parties du code, si tu fais ça.

    Trolleur :)

    Certes, mais je ne parviens toujours pas à comprendre l'intérêt de l'introspection.

    Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.

    Sauf qu'il faut vraiment en vouloir pour défoncer l'encapsulation. À ce moment, on en est plus à de la négligence mais à de la malfaisance. L'encapsulation est un outil qui permet aux développeurs de se protéger d'eux-même. Ce n'est pas un système de protection mémoire.

    Tu mets ce que tu veux dans le set hein, tu peux faire plein de contrôle, discuter avec la voiture toussa.
    Mais oui, ca simplifie l'usage. Si on part de ton principe, cad mettre la méthode changeWheel sur la voiture, faisons de même pour toutes les pièces remplaçable de la voiture (1000 ?), tu fais une façade géante de 1000 méthodes ou tu éclates en un graphe d'objets ?

    En quoi serait-ce pertinent d'exposer les 1000 pièces de la voiture ? C'est typiquement le genre de cas où on aura besoin d'un mécanicien, un objet qui sait comment visiter la voiture et la modifier. Exposer une méthode pour chaque élément de la voiture briserait évidement l'encapsulation et serait stupide.
    Quand au graphe d'objet interne de la voiture, il ne serait pas disponible pour l'utilisateur de la classe, mais uniquement pour des visiteurs.

    Toutafé : on demande au parent (y'a pas le choix tu remplaces), et pas à l'ancètre le plus haut (le document) comme aurait dû y conduire la fameuse loi de Demeter.
    Tu viens de montrer que tu n'as pas compris la loi de Déméter.

    Par code, ça donnerait, pour remplacer un noeud :
    doc.getNode('item3').getChildNode('title').setChildNode(2, new Node("fr-FR"))
    Si on avait suivi la fameuse loi, tu aurais écris quoi ?

    // Et encore, la fonction membre setChildNode n'a pas une signature géniale
    doc.getNode('item3').getChildNode('title').setChildNode(2, doc.createNode("fr-FR")) ;
    

    Je pense que tu as un sérieux problème à séparé les responsabilités. Ici, on veut modifier un arbre XML. C'est le métier du code, donc il n'y a pas de soucis à faire ce qu'on fait ici. Si le XML était plus spécialisé, on aurait des classes et des méthodes plus adaptés, à l'image de DOM HTML.

    Arrête de théoriser, donne nous du code. Je m'évertue à montrer qu'en pratique cette loi ne marche pas, prouve le contraire en mettant l'équivalent de ce que j'écris.

    Je ne théorise pas. C'est toi qui ne comprend pas ce qu'est la loi de minimisation des interaction d'un objet avec d'autres objets. La programmation est une affaire de compromis, ce qui fait qu'appliquer bêtement la loi de Déméter est absurde. Mais c'est tout aussi absurde de la jeter avec l'eau du bain.