Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.
...
Donc, vas-y, donne nous ta version de code qui fait la même chose en respectant la fameuse loi.
Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.
Trolleur :)
Ça n'a rien à voir avec le caractère orienté objet du langage.
Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.
Exemple ?
Tu connais beaucoup d'API qui exposent leurs paramètres avec les types de la STL ? A ton avis, pourquoi ne le font-elles pas ?
Ça dépend du type d'API que tu développe.
Exemple ?
Mais l'assigner directement, c'est chercher les problèmes. Évidement qu'on peut mettre des observateurs dans tout les sens, mais est-ce que sa simplifie vraiment l'usage ?
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 ?
est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.
Si c'est utile pour l'utilisateur, simple et intuitif, oui. Après tu fais ce que tu veux dans le setter pour assurer la cohérence globale. De toute façon le faire dans une fafade géante te conduiras à assurer le même niveau de cohérence.
Est-ce que modifier un nœud modifie l'état du parent ?
Oui potentiellement : si ton noeud parent a une propriété qui indique si elle contient d'autres éléments (HasChild), tu modifies bien son état (d'un point de vu utilisateur).
Tu remarquera que pour remplacer un nœud, dans le DOM, on assigne pas le nœud ou on de modifie pas le nœud : on demande à son parent de le remplacer.
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.
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 ?
Je crois que la loi de Demether a frappé là où tu ne l'attendais pas.
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.
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . 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.
Trolleur :)
Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.
Tu connais beaucoup d'API qui exposent leurs paramètres avec les types de la STL ? A ton avis, pourquoi ne le font-elles pas ?
Exemple ?
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 ?
Si c'est utile pour l'utilisateur, simple et intuitif, oui. Après tu fais ce que tu veux dans le setter pour assurer la cohérence globale. De toute façon le faire dans une fafade géante te conduiras à assurer le même niveau de cohérence.
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.
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 ?
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.