Discussion :

[5:35pm]

je le pense, le mot-cle friend est essenciel a une architecture de qualite. et je dis ca en ayant de bonne connaissance des design-patterns.
Il y a une idee recu, de je ne sais d'ou, que l'usage du mot-clef friend reflete un defaut de conception. et c'est de cela que je voudrais debattre.
certains arguent que "friend" viole le concept d'encapsulation, mais je dirais que ca le renforce. Pour illustrer mon propos, prenons un example simple:


(sans friend)

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
 
class Book
{
public:
   Book(double reference, string title, string author, float price);
   float getPrice() const;
   string getTitle() const;
   string getAuthor() const;
   double getReference() const;
   void setPrice(float price);
 
private:
   double _reference;
   string _title;
   string _author;
   float _price;
};
 
class BookManager
{
   public:
   BookManager& getInstance();
 
   void CreateBook(double reference, string title, string author, float price);   // new Book(...);
   void ChangePrice(double reference, float newprice); //Book::setPrice(...);
 
   private:
   BookManager();
   std::map<double,book*> BookList;
   static BookManager* _instance;
};

(avec friend)

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
 
class Book
{
public:
 
   float getPrice() const;
   string getTitle() const;
   string getAuthor() const;
   double getReference() const;
 
 
private:
 
    Book(double reference, string title, string author, float price); //acessible a BookManager seulement
    void setPrice(float price); //acessible a BookManager seulement
 
   double _reference;
   string _title;
   string _author;
   float _price;
   friend class BookManager;
};
 
class BookManager
{
   public:
   void CreateBook(double reference, string title, string author, float price);   // new Book(...);
   void ChangePrice(double reference, float newprice); //Book::setPrice(...);
 
   private:
   BookManager& getInstance();
   BookManager();
    std::map<double,book*> BookList;
   static BookManager* _instance;
 
};

on considere que le titre, l'auteur et la reference ne change jamais.

l'implementation sans friend expose le constructeur de book a tout objet, ainsi que la modification du prix.

l'implementation avec friend restreint l'instantation, et la modification de book a l'instance unique BookManager. certe BookManager peut mettre la pagaille a tout les membres prive, mais il est plus sur de tout exposer a un ami, que d'exposer quelques membres qu'on aimerai pas publiquement.

qu'en dites vous?

[koala01]

Salut,

Comme pour beaucoup de chose en programmation, on trouve à boire et à manger, y compris pour ce qui est de l'utilisation du mot cle friend...

*De prime abord*, j'aurais effectivement tendance à estimer qu'il n'est pas opportun d'exposer les membre privés d'une classe dans une autre.

La raison est relativement simple: si tu décide de modifier la représentation mémoire d'un membre privé du type dont tu a exposé les membre, tu devra répercuter cette modification dans bien plus d'endroits.

Maintenant, rien n'est jamais ni tout blanc ni tout noir en informatique...

Et, si tu déclare tes amitiés de manière strictement précise et dans des cas strictement identifiés, bref, que tu ne déclare pas des amitiés à tord et à travers, la facilité qu'elles peuvent apporter est malgré tout réelle...

Et, dans ce cas, pourquoi s'en priver

Le tout étant toujours de déterminer les situations dans lesquelles l'amitié permettra de faciliter la conception, sans impliquer *trop* de modifications si on décide de changer une implémentation et dans quelles autre situations elles rendront les modifications *beaucoup* plus difficiles...

En définitive, je dirais:

si possible, faire sans, si vraiment c'est nécessaire... pourquoi pas

[EDIT]ceci dit, il y a quand même un léger problème dans le code avec l'amitié que tu présente:

tu déclares friend BookStore, et tu propose une classe... BookManager

De plus, j'envisagerais, personnellement, plutôt de gérer les livres dans un conteneur associatif. Une std::map me paraitrait franchement pas mal, comme cela, sans trop réfléchir

Je mettrais la référence du bouquin en clé, et le livre en valeur.

De cette manière, je pourrais bien plus rapidement accéder au livre qui m'intéresse, (std::map<double,book>::iterator it=Booklist.find(reference) )et je n'aurais plus qu'à appeler "setprice"
[EDIT 2]je suis même en train de me dire que, tant qu'à faire, je limiterais volontiers l'amitié aux fonctions de BookManager qui en ont vraiment besoin:

• celle qui prend la création du livre en charge
• celle qui s'occupe de la modification du livre
• celle qui s'occupe de supprimer la référence
• l'une ou l'autre que j'aurais oublié

[5:35pm]

voila, corrige/modifie =)
pour ce qui est de donner acces au fonctions qui en on besoin, c'est bien, mais en general je fais ca si pas plus d'une ou deux fonction sont concernes.

La raison est relativement simple: si tu décide de modifier la représentation mémoire d'un membre privé du type dont tu a exposé les membre, tu devra répercuter cette modification dans bien plus d'endroits.

alors la je comprend pas vraiment, au contraire meme, si l'ont modifie la structure, de book par exemple, seul BookManager est concerne.

les "vertus" de friend, je le vois particulierement bien dans une relation objet/manager, ou des objets qui "travaillent ensemble" mais pas n'import'ou.
C# a un mot clef que j'utilise beaucoup qui est "internal" utilise pour rendre accessible des membres seulement aux objets declare dans le meme espace de nom. tres pratique pour limiter l'exposition aux objets "proche".

[koala01]

alors la je comprend pas vraiment, au contraire meme, si l'ont modifie la structure, de book par exemple, seul BookManager est concerne.

Dans le code que tu présentes, on est effectivement dans le cadre d'une utilisation "cohérente" de l'amitié, et la remarque ne s'applique pas...

Par contre, et c'est surtout là dessus que je voulais insister, si tu utilises l'amitié à tord et à travers, que, parce qu'il y en a qui ne seraient pas gênés de le faire, tu commence à déclarer un nombre important d'amitiés diverses et variées pour une seule et même classe, tu fusille littéralement le concept de l'encapsulation des données... et là, bonjour les dégâts

[koala01]

les "vertus" de friend, je le vois particulierement bien dans une relation objet/manager, ou des objets qui "travaillent ensemble" mais pas n'import'ou.

Voilà bien la preuve que nous sommes d'accord: dans un cadre bien précis, quand c'est nécessaire ou très utile...

Mais il est vraiment, je pense du moins, très important d'insister là dessus... Sinon, d'ici à ce que l'on voie "fleurir" les friend comme fleurs au printemps sous prétexte que "ce n'est pas si grave"... il n'y a qu'un pas que certains pourraient franchir avec énormément d'allégresse

[5:35pm]

carrement =)
on est d'accord, et c'est ca le probleme, un debat c'est marrant quand on est pas d'accord

Il est pourtant clair que friend a mauvaise reputation, par exemple, j'ai recemment lu l'article de Aurélien Regat-Barrel sur la gestion des ressources.
on peut voir lors de sa premiere tentative d'implementation l'utilisation d'un friend donnant a Ressource l'acces aux membres prive de ressource manager. ensuite il commente:

L'utilisation du mot-clé friend est lui aussi souvent un indice d'une mauvaise conception

a la deuxieme version

Certes, il reste l'utilisation du mot-clé friend, mais ce dernier porte cette fois sur une classe imbriquée privée de ResourceManager, et n'est donc pas choquante.

Afin d'eviter l'amitiee, la derniere implementation est concu pour ne pas l'autoriser; qui AMHA n'est pas mieux que la deuxieme version que je trouve plus elegante.

[screetch]

Il y a deux facons de jouer avec friend :


- J'ai des methodes privees mais machin en a besoin :-/ allez je passe Machin en firend

forcement ca donne l'impression de violer les lois d'encapsulation

- J'ai des methodes publiques sensibles, mais seul Machin s'en sert. Je vais limiter leur portee et autoriser MNachin a y acceder comme ca pas d'erreur

et la Friend sauve le monde.

A voir comment vous presentez les choses.


Dans le cadre de la programmation C++ ca arrive souvent de tout diviser en modules (a peu pres des classes) et de diviser ensuite des classes en trucs encore plus petit (invisible a l'utilisateur, comme le pattern pimpl par exemple, ou bien 3 classes qui font le taf mais une seule est exposee au reste du monde).

Dans ce cas les classes doivent etre friend entre elles sinon l'API publique grandit pour rien.

Mais Joueur friend avec Projectile pour verifier sa vitesse, ca non!

[Alp]

En effet, beaucoup utilisent friend histoire d'écrire moins de code. C'est une solution de facilité pour le coup du Joueur et du Projectile. Et c'est complètement inutile dans beaucoup de cas.
On pourra toujours ne pas se servir de friend (=> faire autrement), après il y a des cas où friend ne casse rien ou pas grand chose, et l'on peut l'utiliser en toute tranquilité.

Donc vraiment, il faut réfléchir à deux fois avant d'écrire friend dans son code.

[befalimpertinent]

Je suis entièrement d'accord avec ce qui a été dit auparavant et j'aimerais avoir votre avis sur un autre type d'utilisation courant de friend. Il est pas rare de voir dans des classes le mot clé friend utilisé pour des fonctions pour permettre une écriture plus facile et plus élégante d'une opération dans le reste du code.

Un petit exemple pour être plu clair. Une bête classe Point3D. Si je veux la distance entre deux points A et B je peux avoir une fontion membre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Class Point3d
{
private:
   double x;
   double y;
public:
   Point3d(double x0, double y0);
   double distance(const Point3d &b);
}

Mais dans ce cas dans le reste du code il faudra écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Point3d a(0.5,0.5);
Point3d b(1.5,3.5);
double len_ab = a.distance(b);

Convenons que cette manière d'écrire un calcul de distance n'est ni très élégante ni même très correcte (problème de symétrie)
Alors qu'avec l'utilisation de friend :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Class Point3d
{
private:
   double x;
   double y;
public:
   Point3d(double x0, double y0);
friend double distance(const Point3d &a,const Point3d &b);
}

On aura plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Point3d a(0.5,0.5);
Point3d b(1.5,3.5);
double len_ab = distance(a,b);

C'est exemple est peut être trop simple (coordonnées en visibilité public peut être ou accès par getter/setter serai bien meilleur) mais il sert juste à illustrer mon propos.
La question est faut-il encourager ce genre de syntaxe ? Si oui dans quel(s) cas ? Sinon ... mais heu... pourquoi ?

[bolhrak]

Dans le cas de ton exemple j'aurais tendance à utiliser cette notation, "plus naturelle" en ce qui concerne ce type de fonction (mathématique). Une solution pour garder cette notation sasn utiliser friend serait de déclarer ta méthode statique.

Sinon de manière générale le mot clé "friend" me sert à compenser le manque d'exportation limitée des caractéristiques en C++. En gros à chaque fois que j'aimerais qu'une méthode/donnée membre soit publique pour une/quelques classes précises mais pas le reste du monde, le friend est un bon candidat.

[r0d]

Un autre cas où l'amitié est trés utile, c'est le cas de la surcharge d'opérateurs qui nécessitent une instance de la classe considérée en paramètre. Typiquement, l'opérateur d'indirection de flux.

Maintenant, ce n'est qu'un cas particulier de ce que vous avez dit, à savoir que parfois il est préférable, même du point de vue de la conception (et surtout de ce point de vue), de permettre à une classe d'accéder à des attributs privés plutôt que de rendre publique un attribu qui ne devrait pas l'être.

D'autant plus que l'on peut aisément pallier au fait qu'une classe ou fonction amie accède à tous les membre privés (donc éventuellement à certains membres auxquel nous ne souhaiterions pas autoriser l'accès) par l'utilisation de l'idiome pImpl.

Enfin, si ce mot-clé existe, c'est qu'il a son utilité. C'est comme pour mutable: certains considèrent l'utilisation de mutable comme une hérésie. En ce qui me concerne, il m'est arrivé que son utilisation se soit révélée parfaitement légitime et propre.

[JolyLoic]

Un autre cas où l'amitié est trés utile, c'est le cas de la surcharge d'opérateurs qui nécessitent une instance de la classe considérée en paramètre. Typiquement, l'opérateur d'indirection de flux.

C'est amusant, car bien que n'ayant pas de préjugés anti-friend, je l'utilise rarement dans ce cas. En général, soit j'ai moyen de l'écrire sans faire appel aux données privées, soit je suis dans une hiérarchie, et donc une fonction virtuelle display s'impose.

Autrement, ça fait déjà un moment que je suis convaincu que friend augmente l'encapsulation, ce que j'aimerais en fait, ce serait la possibilité d'avoir des amis partiels, tel amis ayant le droit d'accéder à telle ou telle sous partie de ma partie privée. Il y a certes moyen de simuler ça dans des cas simples avec un pimpl, mais c'est assez lourd.

Pour mutable, 100% d'accord, j'ai du mal par exemple à voir comment mettre en cache une propriété calculée sans ça (ou alors à coup de const_cast, mais là, ça devient mauvais, on peut modifier trop de choses). Les gens qui critiquent (il y en a vraiment ?) confondent constance physique et constance conceptuelle, seule la seconde ayant un intérêt à mon sens (à par la constance à la compilation, mais c'est autre chose).

[Alp]

Tu as raison, cependant je vois souvent défiler des code où friend est utilisé à tout va. C'est ça qu'il faut arrêter.

Après en effet le concept d'ami est à approfondir.

[screetch]

une bonne pratique que j'ai vue (mais curieusement je m'y suis jamais mis) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class MaClasse
{
    friend class MaClassImpl;
    friend class Helper;
private: //friend MaClassImpl;
    void doStuff();
private: // friend Helper
    void doStuff2();
    void doOtherStuff();
private:
    void createImpl(); //friend avec personne
public:
    ....
};

Ca ne force pas le compilo a verifier mais ca aide a la relecture. Apres rien n'empeche de mentir comme un dentiste et que les classes accedent a plus que le commentaire.

Ce qui serait cool ca serait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class MaClasse
{
friend class MaClassImpl: //sous entendu private
    void doStuff();
friend class Helper: //sous entendu private
    void doStuff2();
    void doOtherStuff();
private:
    void createImpl(); //friend avec personne
public:
    ....
};

[Mat007]

Salut,

Je vais vous faire plaisir pour votre débat car je suis dans une large mesure pas d'accord

Je n'utilise presque jamais friend, quand je le fais c'est temporaire et il disparait en général au remaniement suivant (je parle du friend de classe à classe).
Je comprends les arguments, avancés notamment par certains auteurs 'célèbres' (impossible de retrouver les références mais je jurerais avoir lu ça à plusieurs reprises dans la littérature), mais rien n'y fait.
Pour moi friend est l'encapsulation du faignant !
C'est un signe qu'une classe fait trop de choses : si elle a besoin d'être vue sous deux angles différents c'est vraisemblablement qu'elle cumule au moins deux fonctionnalités.
Une classe comme ça il faut à mon sens peut-être la couper en deux, et de toute façon lui définir deux types différents.

En fait je m'aperçois en rédigeant ma réponse que le concept même est complètement incompatible avec ma manière de développer.
Mes classes sont soit des interfaces (que des virtuelles pures) soit des classes concrètes (implémentent en général une seule interface, des fois quand même quelques unes), elles ont rarement plus de 5 méthodes (en comptant les 'helpers' privées et faisant 5 lignes chacune) et dans la plupart des cas ne gèrent qu'une seule fonctionnalité.
La granularité de mes classes est donc au final très faible, du coup forcément utiliser un friend n'a plus trop d'intérêt et se retrouve vite fait remplacé par une interface.
Surtout qu'une classe concrète ne parle en général de toute façon qu'à des interfaces...


L'exemple est un peu biaisé je trouve dans la mesure où Book est typiquement une 'classe-qui-ne-sert-à-rien' à mon sens (aucun traitement, que des mutateurs/accesseurs).
Mais c'est jamais évident de trouver des exemples simples pour des concepts, c'est sûr...

Enfin bon là je ferais ça, pour donner une idée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Book_ABC
{
public:
  virtual float getPrice() const = 0;
  virtual string getTitle() const = 0;
  virtual string getAuthor() const = 0;
  virtual double getReference() const = 0;
};
 
class Priceable_ABC
{
public:
  virtual void setPrice( float price ) = 0;
};
 
class Book : public Book_ABC, public Priceable_ABC
{
  // ...
};

Ca me fait froid dans le dos d'écrire autant d'accesseurs mais c'est l'idée, tout dépend de l'utilisation qui en est faite aussi...


MAT.

[screetch]

Dans le principe pourquoi pas, mais tu as mis ici dans la classe Book une methode setPrice publique, du coup tout le monde peut bidouiller le prix sans que le compilateur te jette. Comment faire pour modifier le prix par certaines entites seulement ?

[NiamorH]

Ce mot clef m'est indispensable, personellement. Ne serait-ce, comme on l'a dit, pour écrire les operateurs binaires +-*/, mais aussi surtout pour protéger l'interface de fonctionnement interne des classes d'un même système un peu complexe et ne laisser public que les méthodes à utiliser par le programmeur.

Une question cependant, concernant l'amitié réciproque et les templates.
Pourquoi ce code ne compile-t-il pas :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
template <class T>
class Mere
{
private:
  friend class T;
private:
  Mere();
  Mere( const Mere<T> & );
  Mere<T> & operator =( const Mere<T> & );
};


class Fille : public Mere<Fille>
{
private:
  friend class Mere<Fille>;
public:
  Fille() : Mere<Fille>() {}
};

int main()
{
  Fille f;
  return 0;
}

A noter qu'il suffit de mettre le constructeur par defaut de Mere en protected pour que celà fonctionne alors.

error C2248: 'Mere<T>::Mere'*: impossible d'accéder à private membre déclaré(e) dans la classe 'Mere<T>'
with
[
T=Fille
]
and
[
T=Fille
]
and
[
T=Fille
]

[Alp]

Car la fille hérite seulement de ce qui est protected et public.

La fille ne pourra dans ton exemple jamais appeler le constructeur de Mere, donc ne pourra jamais être créée.

[Mat007]

Dans le principe pourquoi pas, mais tu as mis ici dans la classe Book une methode setPrice publique, du coup tout le monde peut bidouiller le prix sans que le compilateur te jette. Comment faire pour modifier le prix par certaines entites seulement ?

Et bien tu donnes à 'tout le monde' des Book_ABC à manipuler sauf à BookManager qui lui reçoit des Priceable_ABC (ou des BookPriceable_ABC si nécessaire, ça dépend de ses besoins)...

La classe concrète Book n'existe que pour la factory qui les instancie, tout le reste du système ne voit que les types définis par les interfaces.

MAT.

[screetch]

Salut,

une reponse plus precise existe avec Visual C++ 2008 beta 2 codename Orcas (ouf!)

l'erreur devient :

------ Build started: Project: test, Configuration: Debug Win32 ------
Compiling...
stdafx.cpp
Compiling...
test.cpp
c:\boost\test\test\test.cpp(7) : error C2649: 'typename' : is not a 'class'
c:\boost\test\test\test.cpp(12) : see reference to class template instantiation 'Mere<T>' being compiled
c:\boost\test\test\test.cpp(20) : error C2248: 'Mere<T>::Mere' : cannot access private member declared in class 'Mere<T>'
with
[
T=Fille
]
c:\boost\test\test\test.cpp(9) : see declaration of 'Mere<T>::Mere'
with
[
T=Fille
]
Build log was saved at "file://c:\boost\test\test\Debug\BuildLog.htm"
test - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

En effet il est interdit par le standard C++ de devenir friend avec une classe passee en parametre de template. Je verrai si je peux retrouver le texte dans l'aprem.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
template<class T>
class Test
{
    friend class T;
};

est invalide et ne devrait pas compiler.

le compilateur Comeau renvoie l'erreur :

"ComeauTest.c", line 5: error: template parameter "T" may not be used in an
elaborated type specifier
friend class T;