Folco (./65) :
Et que penses-tu de sa solution, toujouts en ./43, qui passe par un un objet dont hérite vélo, dont on passe le pointeur à EditVélo et à Affiche Vélo ?

Bah c'est de celle-ci dont je parlais : tu as le choix entre passer un "const Velo&" ou faire une interface "ReadOnlyVelo" dont hérite "Velo" et qui n'expose que la partie lecture sans l'écriture. Les deux sont fonctionnellement équivalentes, techniquement const sera un poil plus efficace si ça te permet de ne pas passer tes méthodes en virtuel, mais ici j'imagine qu'on s'en fout complètement.

Tout comme mutable est fait pour violer volontairement const, et pourtant tu m'as dit qu'il avait son utilité.

C'est pour ça que je dis "dans ce cas précis" dans ./64. Le mot-clé const fait beaucoup de choses en C++ (peut-être trop), et je trouve qu'il y a des cas très précis où ça peut être intéressant d'utiliser mutable. Tout comme il y a des cas très précis où ça peut être intéressant d'utiliser friend, sauf qu'à mon avis ces cas-là se limitent essentiellement à du test.

Sauf que ce que je proposais me semblait proposer la simplicité, sans le viol de l'encapsulation, étant donné qu'il était question d'être friend avec une classe bien précise, et justement pas avec n'importe qui. C'est sur cette facette que j'aurais aimé avoir un avis autre que "ça viole l'encapsulation" (je suis au courant et c'est le but) et "c'est pas bien" (euh...).

Tu me demandais mon avis (tu m'as même !call pour ça), je te le donne : je n'ai jamais vu de bonne utilisation de friend dans des cas similaires à celui que tu présentes, donc je pense que ça n'est pas une bonne solution ici. Ça ne veut pas dire que c'est universellement vrai, et si mon avis n'est pas celui que tu voulais entendre j'en suis désolé, mais ça ne le change pas pour autant ^^