Bah ca peut être le controller de l'application tout simplement.
C'est bien ça le problème, le tout simplement. On risque d'avoir beaucoup de complexité dans le contrôleur si on commence comme ça.
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.
:D
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.
Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.
L'introspection ?
Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.
Le fait que pleins de type de base ne soit pas eux-même des objets ?
Ça dépend ce qu'on appelle un objet.
Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?
C'est un avantage de C++ sur Java. De mettre toute le code dans une classe peut poser des problèmes d'encapsulation. Pourquoi une fonction facrory devrait absolument avoir accès aux membres privés ?
Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?
Ça n'a rien à voir avec le caractère orienté objet du langage.
Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?
Exemple ?
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.
Ça dépend du type d'API que tu développe. C'est toujours le même problème : qu'est-ce qui peut être exposé, et à quel usage est destiné le composant.
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.
Récupérer le pneu, oui, puis le modifier et le remplacer. 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 ?
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.
Moi aussi je m'attends à ce que le composant enfant ait cette fonctionalité. Mais lorsque tu composes une vue, et que l'ensemble de la vue nécessite des calculs particulier pour l'affichage, est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.
Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.
Est-ce que modifier un nœud modifie l'état du parent ? 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. Pareil pour créer un nouvel élément, on demande au document un nouveau nœud. Je crois que la loi de Demether a frappé là où tu ne l'attendais pas. D'ailleurs, ici, la logique métier c'est la gestion d'un arbre XML, et les méthodes exposées exposent bien les fonctionnalités de gestion de l'arbre.
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.
Je pense que c'est complémentaire, comme toujours, une succession de compromis.
[^] # Re: Chacun son style
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
C'est bien ça le problème, le tout simplement. On risque d'avoir beaucoup de complexité dans le contrôleur si on commence comme ça.
:D
Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.
Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.
Ça dépend ce qu'on appelle un objet.
C'est un avantage de C++ sur Java. De mettre toute le code dans une classe peut poser des problèmes d'encapsulation. Pourquoi une fonction facrory devrait absolument avoir accès aux membres privés ?
Ça n'a rien à voir avec le caractère orienté objet du langage.
Exemple ?
Ça dépend du type d'API que tu développe. C'est toujours le même problème : qu'est-ce qui peut être exposé, et à quel usage est destiné le composant.
Récupérer le pneu, oui, puis le modifier et le remplacer. 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 ?
Moi aussi je m'attends à ce que le composant enfant ait cette fonctionalité. Mais lorsque tu composes une vue, et que l'ensemble de la vue nécessite des calculs particulier pour l'affichage, est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.
Est-ce que modifier un nœud modifie l'état du parent ? 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. Pareil pour créer un nouvel élément, on demande au document un nouveau nœud. Je crois que la loi de Demether a frappé là où tu ne l'attendais pas. D'ailleurs, ici, la logique métier c'est la gestion d'un arbre XML, et les méthodes exposées exposent bien les fonctionnalités de gestion de l'arbre.
Je pense que c'est complémentaire, comme toujours, une succession de compromis.