Discussion :

[Difré91]

Bonjour à tous,

J'ouvre ce topic pour recenser les "bonnes" utilisations du mot clef friend appliqué à une classe (pas à une fonction).

J'ai fait des recherches sur le net, mais je ne trouve que très peu d'exemples.
Avec quel design patterns peut-on l'utiliser, dans quels cas est-il (quasiment) obligatoire d'y avoir recours ?
Plus concrètement, comment vous en servez-vous dans vos projets ?

Merci d'avances pour vos contributions.
En espérant n'être pas trop vague dans ma demande.

[JolyLoic]

C'est un peu vague en effet, et du cou ma réponse le sera aussi

(quasi) obligatoire, jamais.

Préférable : Quand l'alternative à l'utilisation de friend serait de passer en public des fonctions qui n'ont pas vocation à être appelées par n'importe quel utilisateur de la classe.

Un exemple : dans la bibliothèque boost.serialization, le code pour désérialiser un objet a besoin que la classe possède un constructeur par défaut. Dans une classe qui n'aurait pas naturellement un tel constructeur, donner accès à ce détail technique d'implémentation pourrait conduire à de mauvaises utilisations de la classe. Donc, ce constructeur reste privé, mais on rend la classe friend de la classe qui réalise la désérialisation (d'autres fonctions demandent aussi ce friend, mais je trouve le cas du constructeur par défaut très parlant).

[Difré91]

Merci pour ta réponse.

Si j'ai bien compris, c'est la classe à sérialiser qui déclare le sérialisateur friend ?

Si je devais rattacher un design pattern, ce serait plutôt du factory non ?
Une classe qui a besoin d'en instancier une autre, mais sans passer par le constructeur normal (qui prendrais en général des valeurs d'attributs en entrée).

Ce lien présente un autre exemple, une classe d'affichage, qui prend l'objet principal en paramètre. Maintenant, je ne comprend pas pourquoi on interdirais l'accès via getter à un attribut, si c'est pour l'afficher après. Dans une cas où on autorise seulement un certains formatage pour y accéder ?

[JolyLoic]

Merci pour ta réponse.

Si j'ai bien compris, c'est la classe à sérialiser qui déclare le sérialisateur friend ?

C'est ça, en effet.

Si je devais rattacher un design pattern, ce serait plutôt du factory non ?
Une classe qui a besoin d'en instancier une autre, mais sans passer par le constructeur normal (qui prendrais en général des valeurs d'attributs en entrée).

En effet, mais le fait que ce soit une factory est de peu d'importance pour l'utilisation de friend. Ce qui est important est que la classe possède deux types d'usages très différents. L'un qui est son usage normal, ce pour quoi elle a été prévue, et l'autre qui est un usage spécifique, réservé à quelques cas particuliers. Et l'usage de friend permet d'éviter que les deux usages interfèrent.

Ce lien présente un autre exemple, une classe d'affichage, qui prend l'objet principal en paramètre. Maintenant, je ne comprend pas pourquoi on interdirais l'accès via getter à un attribut, si c'est pour l'afficher après. Dans une cas où on autorise seulement un certains formatage pour y accéder ?

Je pense que cet exemple à plus pour objectif de montrer la syntaxe et le fonctionnement de friend, que son bon usage en terme de design.

[koala01]

Salut,

Ce lien présente un autre exemple, une classe d'affichage, qui prend l'objet principal en paramètre. Maintenant, je ne comprend pas pourquoi on interdirais l'accès via getter à un attribut, si c'est pour l'afficher après. Dans une cas où on autorise seulement un certains formatage pour y accéder ?

Je pense que cet exemple à plus pour objectif de montrer la syntaxe et le fonctionnement de friend, que son bon usage en terme de design.

De manière générale, il faut se méfier des accesseurs car ils ont souvent pour effet... d'exposer un détail d'implémentation.

Une solution possible pour éviter d'exposer un détail d'implémentation qui n'est utile en tant que telle que pour une classe (ou une fonction) bien particulière passe, effectivement, par l'amitié.

Il faut cependant garder en tête le fait que l'amitié est un excellent moyen pour améliorer l'encapsulation que si (et seulement si !!! ) elle est utilisée à dose "homéopathique".

Si tu dois commencer, pour ne pas fournir un accesseur sur un membre de classe, à déclarer une amitié avec une grosse majorité des autres classes de ton projet (ou, simplement, avec plus d'une ou deux classes dirais-je, même si on peut etre très flottant sur le nombre de classes amies ), c'est peut etre qu'il est temps de remettre en cause la décision qui consiste à ne pas fournir l'accesseur à tout le monde.

De plus, une déclaration d'amitié ne devrait, autant que faire se peut, du moins, pas donner le droit à la classe amie d'accéder aux membres directement.

Si tant est que ce soit possible (et qu'il soit cohérent de le faire), il me semble toujours préférable de faire en sorte que l'amitié permette de déplacer une fonction membre de la visibilité publique vers une visibilité restreinte (privée ou protégée) et d'appeler cette fonction depuis la classe amie plutot que de laisser la classe amie accéder directement au membre qui l'intéresse