Version imprimable
Bonjour, ce sujet a déjà peut-être été abordé mais je n'ai pas trouvé.
Je développe sous C++ Builder. A plusieurs reprises, j'ai eu besoin d'accéder à des données déclarées private d'une classe. Ne trouvant pas de fonctions membres qui y accédaient, j'ai simplement modifié la déclaration de la classe dans l'en-tête .h (:oops: ) pour redéfinir la donnée en public.
Ma question est donc la suivante: la protection des données private est-elle donc si peu efficace ?
Le but des spécificateurs d'accès est plus de fournir une restriction sémantique qu'effective, une manière de dire "ne vous préoccupez pas de comment je fais mon travail, contentez vous de me demander le résultat".
Après, tu ne sera pas toujours confronté à une situation où tu as accès au code source de l'application, imagines le cas d'une librairie dynamique ..
Salut,
L'avantage de déclarer des membres privés (ou protégés, si un héritage est prévu), c'est que tu vas pouvoir présenter des fonctions (publiques, elles) utiles à l'utilisateur de la classe, sans qu'il ait besoin de s'inquiéter de comment les membres sont réellement maintenus en mémoire...
Un exemple pourrait etre celui d'une classe "Couleur":
Les couleurs "vraies" (pe: rgb(red, green, blue)) sont, par exemple, souvent utilisées sous la forme d'un char[3], mais tu pourrais décider de maintenir les valeurs sous la forme d'un std::vector<char>...
Si tu laisse le std::vector<char> publique, tu courres le risque que l'utilisateur de la classe crée un code en l'utilisant directement... et, le jour où, par lubie ou suite à un benchmark, tu te rend compte qu'il est plus intéressant de le maintenir en mémoire sous la forme d'un char[3], tout le code créé par l'utilisateur qui utilise ta classe sera... bon à foutre à la poubelle...ou peu s'en faut...
Par contre, si ton membre est privé, il te "suffira" d'adapter les méthodes que tu auras fournies pour gérer le membre en fonction du type utilisé et de fournir une mise à jour de ta classe, sans que cela provoque la perte de tout le code qui en dépend...
Le résultat, y compris pour toi, c'est que d'un coté (membre publique), si tu modifie ne serait-ce qu'un tout petit peu une classe utilisée dans de nombreux fichiers, tu devra vraissemblablement parcourrir tous ces fichiers pour modifier le code, alors que, si le membre est privé, tu n'auras que le fichier dans lequel les fonctions membres permettent un acces au membre à modifier... Avec un gain de temps considérable ;)
La moralité, quand tu crées une classe perso, c'est que tu as plus intérêt à rajouter une méthode d'acces/modification du membre privé qui convienne à tes besoins, plutot que de faire passer un membre d'une visibilité privée à une visibilité publique ;)
A mon humble avis, au lieu de rendre ta variable public tu peux :Citation:
Envoyé par josse95
- Soit définir des accesseurs (comme ça était conseillé plus haut)
- Soit- si tu sais à l'avance quelle classe aura besoin d'accéder à ce membre privé et que t'as pas envi de donner l'accès à d'autres- utiliser le notion de classe "amie" avec la classe en question.
Merci pour vos réponses.
Cela est valable pour le concepteur de la classe. Ma manip (douteuse, je le reconnais) concernait des classes que je n'avais pas écrites (VCL de C++ Builder). Je m'étonnais juste que la "protection des données privées" soit si facile à contourner.Citation:
Neo41 a écrit:
si tu sais à l'avance quelle classe aura besoin d'accéder à ce membre privé et que t'as pas envi de donner l'accès à d'autres- utiliser le notion de classe "amie" avec la classe en question
Cela dit, puisque comme le dit NewbiZ, "Le but des spécificateurs d'accès est plus de fournir une restriction sémantique qu'effective", je comprends mieux que cela soit possible.
Note que ta manip ne fonctionne que par hasard, elle introduit un comportement indefini parce que ton programme ne respecte pas la regle de la definition unique (ODR pour les intimes).
Et le fait que cette manip fonctionne est-il spécifique à C++ Builder ou cela est-il général ?
J'aurais tendance à penser que c'est le cas avec tous les compilateurs car je ne vois pas comment ceux ci pourraient se prémunir contre ce type d'opérations, que ce soit lors de la compilation (impossible), de l'édition de liens ou de l'exécution.
Il est vraisemblable que cela ait l'air de marcher avec la plupart des compilateurs, dans la plupart des circonstances. Mais quand on se mets a entrer dans les comportements indéfinis, les effets sont parfois tres bizarres. En particulier quand les optimiseurs entrent en jeu. Apres tout, c'est un comportement indefini et alors il peut se passer n'importe quoi, meme avant l'execution du code ayant le comportement indefini pour autant qu'on soit assure d'y passe (exemple classique, ce qui se passe avec de l'analyse de valeurs possibles qui peut decider qu'un test est toujours faux parce que s'il n'est pas faux on a un comportement indefini par la suite).Citation:
Envoyé par josse95
Il me semble que la norme ne garantit pas la position/l'ordre des variables de niveaux d'accès différents : Seulement celui des variables ayant le même niveau d'accès...
(d'après la doc de Visual, qui lui garantit l'ordre pour la classe entière).
C'est une des choses qui peuvent varier. Plus subtil, un optimiseur pourrait -- je n'en connais pas qui le fond, mais je suis loin d'etre un specialiste -- constater qu'un invariant entre membres donnees privees est maintenu par les membres fontions et en profiter. Si le petit jeu ci-dessus casse l'invariant, le code va faire n'importe quoi.Citation:
Envoyé par Médinoc
(Pour info, il existe deja des optimiseurs qui changent un tableau de structures en une structure de tableau apres avoir remarque que le programme ne faisait rien de conforme qui profitait de la difference -- l'objectif etant de gagner en localite et donc de mieux profiter des caches).