Comment instancier une friend class ?
En fait on m'a fournit un .h où plmusieurs classes sont déclarées à l'interieur même d'une classe en "friend class"
C'est la premiere fois que je vois çà et je vois pas trop comment faire.
 
merci.
 

ben le friend ici joue quedalle
 
si par exemple t'as :
 

 
et que tu veux instancier titi, tu fais :

friend te permet de déclarer une classe A qui sera autorisée à violer l'encapsulation de la classe B dans laquelle est défini le friend.
 
Une bonne conception permet d'éviter ce genre de magouille.

 
Euh, il a dit "déclaré" pas "implementé"...

 
voila ce que j'ai vu, de la j'ai pense qu'il se focalisait sur le friend alors que ce le vrai soucis c t le cote nested
 
roooh et pis .......

 
Juste pour rire, va regarder un jour le bouquin de reference sur les design pattern. Tu va constater par toi même qu'il y en a. Pourtant, c'est justement une bible sur la conception objet cet ouvrage...
Donc je crois que ton affirmation est fallacieuse.

 
Malgré tout, force est d'admettre que l'utilisation de friend gêne à la propreté du modèle objet ...

 
Non, en C++, le friend ameliore la conception objet et l'encapsulation
 
En fait, selon moi friend doit etre utilise non pas pour fournir un access au donnees privees, mais pour fournir un canal de communication privilegie a certaines donnees. Utilise dans une situation ou le programmeur a le controle des deux classes concernees, cela permet d'ouvrir une voie de communication reservee entre ces deux classes sans pour autant donner l'access a toutes les autres classes du projet que tu ne controles pas toi meme !
 
C'est ma facon de voir l'utilite de friend

ouaip, pareil, parfois je regrette qu'il n'y ait pas qqchose de plus fin que private/public

 
Ben, oui ça viole le fondement même du paradigme objet : l'encapsulation

non, faut pas confondre mettre à disposition des gens uniquement ce qui les concernes et se foutre à poil devant ses potes.
 
Le système "friend" permet à l'ami en question de prendre ce qu'il veut, y compris de taper dans les champs qui ont des contrats à la con (genre qui ont un cache local etc.).
 
Un bon système est d'exporter une interface vers un destinataire ; c'est à dire que seul les objets instances du destinataire ont accès aux éléments exportés (méthode, champ, attribut, événement, types internes divers et autres bordels qu'on peut trouver dans une classe suivant le langage) mais pas plus. Si l'élément est exporté vers une autre classe, il n'y a pas accès, de même si l'élement est privé.
 
C'est en gros le système de droits d'accès aux classes d'Eiffel.

 
à méditer: (source http://www.parashift.com/c++-faq-l [...] #faq-14.2)
 
Do friends violate encapsulation?
No! If they're used properly, they enhance encapsulation.  
 
You often need to split a class in half when the two halves will have different numbers of instances or different lifetimes. In these cases, the two halves usually need direct access to each other (the two halves used to be in the same class, so you haven't increased the amount of code that needs direct access to a data structure; you've simply reshuffled the code into two classes instead of one). The safest way to implement this is to make the two halves friends of each other.  
 
If you use friends like just described, you'll keep private things private. People who don't understand this often make naive efforts to avoid using friendship in situations like the above, and often they actually destroy encapsulation. They either use public data (grotesque!), or they make the data accessible between the halves via public get() and set() member functions. Having a public get() and set() member function for a private datum is OK only when the private datum "makes sense" from outside the class (from a user's perspective). In many cases, these get()/set() member functions are almost as bad as public data: they hide (only) the name of the private datum, but they don't hide the existence of the private datum.  
 
Similarly, if you use friend functions as a syntactic variant of a class's public access functions, they don't violate encapsulation any more than a member function violates encapsulation. In other words, a class's friends don't violate the encapsulation barrier: along with the class's member functions, they are the encapsulation barrier.  
 
(Many people think of a friend function as something outside the class. Instead, try thinking of a friend function as part of the class's public interface. A friend function in the class declaration doesn't violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class's non-public parts.)