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

[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!

[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