Les amis de mon père ne sont pas mes amis, pourquoi ?

Une petit question de culture générale de programmation.

Exemple :
Soit Ami une class
Soit Pere une class de base dont dérive Class1, Class2, Class3.
Pere est ami de Ami. Donc Ami à accès aux parties private et protected de Pere.
Mais Ami n'est pas ami de Class1, Class2, Class3....
C'est une étrangeté je trouve....

Quelqu'un sait-il pourquoi c'est ainsi ?

Des théories :
-> Il y a des cas dans le langage ou cela poserai des problèmes, je ne vois pas où.

-> C'est comme ça et c'est tout.

-> C'est pour faire comme dans le vraie vie.

Si vous pouvez m'éclairer. Merci.

Tu voudrais qu'en déclarant Ami ami de Père, Ami puisse accéder à la partie privée de Class1, Class2, Class3... ?
C'est plutôt à toi de justifier ce comportement :D
Note que Class1 n'a pas accès au private de Père, et inversement.

Oui mais attention si class 1,2 et 3 ont de nouvelles données qui ne sont pas dans pere il est compréhensible qu'on ne veuille pas que une class Ami même si elle est ami de Pere puisse y acceder.

EDIT:Ce message vient a la suite du premier!
Encore une fois je me suis fait griller à 3 secondes prés!

2 (longues) minutes, pas 3 secondes http://arb.developpez.com/smileys/hihihi.gif

Je m'explique :
Je créais pour un moteur de particules des emetteurs...
Le moteur ne connait pas le type des emetteurs qu'il manipule
J'ai une class de base pour les emetteurs (virtual pure)
Une class Engine, le moteur comme vous l'avez deviné.
L'utilisateur, pour définir un emetteur, dérive la class de base...
Le moteur pour faire les claculs sur les emetteurs doit-être ami de ces derniers...
Au début je pensais donc qu'en mettant ma class de base des emetteurs en friend, alors toutes les class dérivées allaient être avoir comme copain le moteur...
Du coup je suis obligé de mettre en public tout ce dont le moteur doit avoir acces, pour que le moteur puisse acceder aux éléments des emetteurs... même ce qui est dans la class de base...

Pourquoi tu manipules les types feuilles dans ton moteur ? (puisque tu as une hiérarchie visblement polymorphe)

Non, j'utilise le polymorphisme...
Mais comme l'objet que j'envoie à été dérivé alors l'amitié ne fonctionne plus...

Tu as un problème de design dans ton moteur, je pense. Tu dois pouvoir le faire différemment.
Crée des accesseurs virtuels en protected par exemple, ou change l'interface en mettant l'interface elle-même en protected et la partir visible que tu appelles en public, ...

L'amitié traduit souvent un mauvais design. Pourquoi en as-tu besoin ?

Ou autre question : pourquoi créer des membres private pour juste après dire "ben ils sont plus private grâce à friend" ?

Citation:

---

Envoyé par Aurelien.Regat-Barrel

L'amitié traduit souvent un mauvais design. Pourquoi en as-tu besoin ?

---

Je ne suis pas vraiment d'accord, même si c'est effectivement un bruit qui court. L'amitié permet une meilleure encaspsulation. A ce titre, c'est une bonne chose.

Exemple récent :
Une classe à verrouiller dans un contexte multithread. Cette classe a une fonction lock et une fonction unlock. Je veux créer un objet qui possède le lock afin de profiter du RAII.

Si je met mes fonctions lock et unlock publiques, je n'ai aucune assurance que l'utilisateur utilisera le RAII pour verrouiller mon objet.

Je les met privées, et je déclare mon objet de lock friend de cette classe. Je ne vois pas comment faire aussi bien et aussi encapsulé sans friend.

Maintenant, il est vrai qu'en général, quand A est friend de B, A et B sont déclarées dans le même .h, car ce sont des classes concues pour travailler étroitement ensemble.

Citation:

---

Tu as un problème de design dans ton moteur, je pense. Tu dois pouvoir le faire différemment.

---

Ben en fait, l'utilisateur des emetteurs ne doit pas avoir accès aux données, mais le moteur doit pouvoir y acceder...
Donc à part l'amitié...
Je ne vois pas ce qui pose un problème de design...
Les emetteurs stockent les infos, et le moteur les traite.