Quel est le sens pour, un objet qui a accès à l'objet app, de modifier un détail de la représentation des données à l'écran ?
Bah ca peut être le controller de l'application tout simplement.
Où n'importe quoi, on s'en fou pas mal, ce qui compte c'est que ce type d'API existe réellement : il t'expose un arbre d'objets, et les méthodes sont placés sur les noeuds où c'est intuitivement là que tu les chercherais. Tu peux te placer au niveau que tu veux, imaginer le scénario que tu veux, l'API restera la même.
Ben oui, ils savent pas, ils font pas. Sauf si tu as une loop qui tourne fear
C'était ironique, j'ai indiqué la solution juste au-dessus : le patron de conception observateur. C'est pas de la théorie, c'est comme ça que c'est fait en pratique.
Je ne le ferais pas car ça n'a pas de sens, dans le cas présent.
Se cacher derrière la sémantique de l'exemple, c'est petit :) Imagine toi le scénario que tu veux, l'API reste identique.
Est-ce qu'un composant graphique doit être modifiable par n'importe quelle portion du code qui l'utilise ?
Quelque soit la portion de code, il faut qu'ils soient modifiables : tu fais l'API de composants graphiques, tu ne sais pas qui ni comment il va l'utiliser. Tu dois par contre exposer tes services : accès composant, modification des composants, etc.
Mais si tu vois un concept manquant, je suis tout ouïe.
L'introspection ?
Le fait que pleins de type de base ne soit pas eux-même des objets ?
Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?
Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?
Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?
Je suppose que tu voulais dire que la mercedes a la fonction :o)
Je voulais dire "que la mercedes ai la fonction" ;)
des boîtes noires avec une interface pour faire des choses
Ce que j'essai d'expliquer, c'est que cette fameuse interface peut être explosée en plusieurs interfaces et présentée à l'utilisateur sous la forme d'une arborescence, sans pour autant exposer plus d'information et donc enfreindre le principe d'encapsulation.
La loi de Demeter a un objectif, certe louable, mais qui ne penses pas utilisateur : quand tu fais une API, tu la conçois de telle sorte qu'elle soit simple, intuitive et aisée à découvrir. Si on suit la loi de Demeter, on a une espèce de façade géante à tous les étages : non seulement l'objectif n'est pas atteint (pleins de méthodes proxy totalement inutiles, donc plus de code à maintenir) mais ca fait une API totalement bloated.
Dans une API de voiture, je m'attend à pouvoir accéder au pneu sur l'objet roue que j'ai récupéré sur la voiture. Je m'attend pas à avoir 15000 méthodes directement sur mon objet voiture.
Dans une API de composants graphiques, je m'attends à ce que la méthode de redimensionnement d'un objet soit sur l'objet concerné, pas sur son parent, son grand-parent ou sa soeur.
Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.
Mais je penses qu'on est dans 2 façon différentes de penser :
* Je penses API, composants réutilisable par un tiers
* Tu penses objet et logique métier.
C'est pas forcement contradictoire, mais ce qui est sûr, c'est que la loi de Demeter est beaucoup trop théorique pour être applicable dans toutes les situations en pratique.
[^] # 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.
Bah ca peut être le controller de l'application tout simplement.
Où n'importe quoi, on s'en fou pas mal, ce qui compte c'est que ce type d'API existe réellement : il t'expose un arbre d'objets, et les méthodes sont placés sur les noeuds où c'est intuitivement là que tu les chercherais. Tu peux te placer au niveau que tu veux, imaginer le scénario que tu veux, l'API restera la même.
C'était ironique, j'ai indiqué la solution juste au-dessus : le patron de conception observateur. C'est pas de la théorie, c'est comme ça que c'est fait en pratique.
Se cacher derrière la sémantique de l'exemple, c'est petit :) Imagine toi le scénario que tu veux, l'API reste identique.
Quelque soit la portion de code, il faut qu'ils soient modifiables : tu fais l'API de composants graphiques, tu ne sais pas qui ni comment il va l'utiliser. Tu dois par contre exposer tes services : accès composant, modification des composants, etc.
L'introspection ?
Le fait que pleins de type de base ne soit pas eux-même des objets ?
Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?
Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?
Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?
Je voulais dire "que la mercedes ai la fonction" ;)
La loi de Demeter a un objectif, certe louable, mais qui ne penses pas utilisateur : quand tu fais une API, tu la conçois de telle sorte qu'elle soit simple, intuitive et aisée à découvrir. Si on suit la loi de Demeter, on a une espèce de façade géante à tous les étages : non seulement l'objectif n'est pas atteint (pleins de méthodes proxy totalement inutiles, donc plus de code à maintenir) mais ca fait une API totalement bloated.
Dans une API de voiture, je m'attend à pouvoir accéder au pneu sur l'objet roue que j'ai récupéré sur la voiture. Je m'attend pas à avoir 15000 méthodes directement sur mon objet voiture.
Dans une API de composants graphiques, je m'attends à ce que la méthode de redimensionnement d'un objet soit sur l'objet concerné, pas sur son parent, son grand-parent ou sa soeur.
Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.
Mais je penses qu'on est dans 2 façon différentes de penser :
* Je penses API, composants réutilisable par un tiers
* Tu penses objet et logique métier.
C'est pas forcement contradictoire, mais ce qui est sûr, c'est que la loi de Demeter est beaucoup trop théorique pour être applicable dans toutes les situations en pratique.