Le soucis est que tu veux faire quelque chose d'aberrant (contrôler le rendu graphique depuis n'importe quel point de l'application).
Réponds par du code s'il te plaît : mon application a besoin de faire la modification que j'ai précisé, moi ca tient en une ligne, que proposes-tu qui soit plus maintenable et qui respecte la fameuse loi ?
Certes, mais je ne parviens toujours pas à comprendre l'intérêt de l'introspection.
L'intérêt ? De travailler au niveau du méta-modèle, de faire de la méta-programmation.
Découverte dynamique de type, de composants (plugins), sérialisation automatique, génération dynamique de proxy, de stub, de service web, programmation par aspect, etc.
Le C++ a essayé d'ajouter un minimum de support à travers le mot clé "typeid", mais ce n'est clairement pas suffisant. Qt a dû modifié le language pour introduire un concept un peu similaire.
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.
Certes, l'exploitation de cette technique est de la malfaisance, mais parfois c'est un simple débordement de tampon par négigeance qui conduit à une faille exploitable (par malfaisance).
L'encapsulation est un outil qui permet aux développeurs de se protéger d'eux-même.
Le soucis du C++, c'est que l'utilisateur d'un composant ne peut pas ignorer sa structure interne : l'organisation des champs pourtant "privés", et la taille globale qu'ils représentent a un impact direct sur son utilisation.
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.
Là encore, tu théorises, sans vouloir écrire de code, mais va jusqu'au bout : tu vas obligé l'utilisateur/visiteur à implenter le pattern visiteur alors qu'il ne veut pas tout parcourir ? Comment vas-tu lui permettre d'atteindre sa cible ? (encore une fois, du code, merci).
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.
Ah bah voilà ! C'est ce que je me tues à expliquer : par nature, certains API exposent "naturellement" pour l'utilisateur un arbre. J'ai pris 2 exemple : une API XML et une API de toolkit graphiques. Et il y a pleins d'autres exemples : API d'introspection, API SGBD, API de dessin vectoriel, API d'impression, API d'automatisation, etc.
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.
On est d'accord, c'est ce que je me tues à expliquer depuis le début : exposer des get/set n'est pas toujours absurde, bien au contraire. c'est pas pour autant qu'il faut systématiquement le faire.
[^] # Re: Chacun son style
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Réponds par du code s'il te plaît : mon application a besoin de faire la modification que j'ai précisé, moi ca tient en une ligne, que proposes-tu qui soit plus maintenable et qui respecte la fameuse loi ?
L'intérêt ? De travailler au niveau du méta-modèle, de faire de la méta-programmation.
Découverte dynamique de type, de composants (plugins), sérialisation automatique, génération dynamique de proxy, de stub, de service web, programmation par aspect, etc.
Le C++ a essayé d'ajouter un minimum de support à travers le mot clé "typeid", mais ce n'est clairement pas suffisant. Qt a dû modifié le language pour introduire un concept un peu similaire.
Certes, l'exploitation de cette technique est de la malfaisance, mais parfois c'est un simple débordement de tampon par négigeance qui conduit à une faille exploitable (par malfaisance).
Le soucis du C++, c'est que l'utilisateur d'un composant ne peut pas ignorer sa structure interne : l'organisation des champs pourtant "privés", et la taille globale qu'ils représentent a un impact direct sur son utilisation.
Là encore, tu théorises, sans vouloir écrire de code, mais va jusqu'au bout : tu vas obligé l'utilisateur/visiteur à implenter le pattern visiteur alors qu'il ne veut pas tout parcourir ? Comment vas-tu lui permettre d'atteindre sa cible ? (encore une fois, du code, merci).
Ah bah voilà ! C'est ce que je me tues à expliquer : par nature, certains API exposent "naturellement" pour l'utilisateur un arbre. J'ai pris 2 exemple : une API XML et une API de toolkit graphiques. Et il y a pleins d'autres exemples : API d'introspection, API SGBD, API de dessin vectoriel, API d'impression, API d'automatisation, etc.
On est d'accord, c'est ce que je me tues à expliquer depuis le début : exposer des get/set n'est pas toujours absurde, bien au contraire. c'est pas pour autant qu'il faut systématiquement le faire.