POO et relation d'amitié – mot clé friend

La plupart des langages OO supportent les relations d'héritage (distinguant parfois l'héritage d'interface et l'héritage d'implémentation), de composition, d'agrégation, d'association, etc. Certains langages supportent aussi d'autres types de relations. En particulier, avec C++, on trouve la relation d'amitié, associée au mot-clé friend, qui donne des privilèges particuliers à une classe ou à une fonction.

L'amitié est une relation à fort couplage, ce qui lui donne parfois mauvaise presse, mais contrairement à certaines croyances populaires, c'est une relation qui, quand elle est bien utilisée, accroît l'encapsulation plutôt que la réduire.

Mise en situation

Prenons un schéma de conception bien connu, soit le schéma de conception Fabrique, par lequel une entité (fonction, classe, objet) a pour responsabilité d'instancier un objet. Il existe plusieurs raisons pour avoir recours à cette technique; dans notre cas, imaginons que nous souhaitons une instanciation en deux temps : création de l'objet, suivi d'un post-traitement exigeant que l'objet ait été pleinement créé, donc que le constructeur ait été complété.

#include <iostream>
#include <thread>
#include <string>
#include <string_view>
#include <utility>
class Machin {
   std::string nom_;
public:
   Machin(std::string_view nom) : nom_{ nom } {
   }
   auto nom() const {
      return nom_;
   }
   void agir() const;
   // ...
};
class FabriqueMachin {
   // ...
public:
   // ...
   static auto creer(std::string_view nom) {
      Machin machin{ nom };
      return std::thread{ [machin = std::move(machin)] {
         std::cout << "Execution en asynchrone de " << machin.nom() << '\n';
         machin.agir();
      } };
   }
};
int main() {
   auto th = FabriqueMachin::creer("R2D2");
   // ...
   th.join();
}

Le changement est simple :

// ...
class Machin {
   std::string nom_;
public:
   //
   // Note : constructeur public (zut!)
   //
   Machin(std::string_view nom) : nom_{ nom } {
   }
   auto nom() const {
      return nom_;
   }
   void agir() const;
   // ...
};
// ...

// ...
class Machin {
   std::string nom_;
   //
   // Note : constructeur privé (yay!)
   //
   Machin(std::string_view nom) : nom_{ nom } {
   }
   //
   // Note : on accorde des privilèges à FabriqueMachin
   // (et on la déclare au passage)
   //
   friend class FabriqueMachin;
public:
   auto nom() const {
      return nom_;
   }
   void agir() const;
   // ...
};
// ...

Avec la version utilisant l'amitié, FabriqueMachin peut instancier Machin, Machin peut (bien sûr) instancier Machin, mais personne d'autre ne le peut car le constructeur paramétrique est privé. Nous sommes donc plus près de notre intention initiale, et nous amélioré l'encapsulation en réduisant l'éventail d'entités pouvant accéder à ce constructeur.

Le mot clé friend

L'amitié, associée au mot clé friend, est souvent décriée dans les milieux OO. On associe souvent ce concept à l'idée de bris d'encapsulation. Pourtant, si on applique le concept avec sagesse, il peut au contraire s'agir d'une manière d'éviter un bris d'encapsulation.

Voyons un peu de quoi il s'agit.

• Une classe peut spécifier, dans sa déclaration, qu'elle a des sous-programmes amis ou des classes amies en ajoutant la mention friend suivie du prototype de cette fonction ou du nom de cette classe
• Un ami d'une classe est un sous-programme ou une classe ayant droit d'accéder aux membres privés ou protégés de cette classe

Notez qu'une déclaration friend peut introduire un nom, à la manière d'une déclaration a priori. Par exemple :

class X {
   friend class Y; // déclare la classe Y et en fait une amie de X
   // friend Z; // illégal car Z n'est pas encore déclarée
};
class Z {
};
class Y {
   friend Z; // Ok, Z est déclarée plus haut
   // (on aurait aussi pu écrire friend class Z ici)
};

Il faut immédiatement établir, à la lecture de cette définition, que la mention friend ne force pas un bris d'encapsulation dans une classe. En effet, une fonction ou une autre classe ne peut pas s'imposer ami(e) d'une classe, la mention friend devant être incluse à même la déclaration de la classe qui s'ouvre à ses amis.

Un ami d'une classe donnée fait partie de l'interface de cette classe, au même titre que ses membres publics et que les fonctions qui sont livrées avec elle. Par conséquent, les amis d'une classe devraient l'accompagner et faire partie du même module (.h/ .cpp) qu'elle.

class Y {
   // ...
   friend class X;
   friend void fy();
   // ...
};
class X {
   // ...
};

Certains utilisent des stratégies OO reposant fortement sur l'amitié, comme par exemple une classe polymorphique servant d'interface et plusieurs classes dérivées dont chaque méthode est privée et qui implémentent les spécialisations des méthodes de leur parent. Dans un tel cas, on trouve, adjointe à chaque classe dont toutes les méthodes sont privées, une fonction amie servant à l'instancier.

Ce que l'amitié n'est pas

Quelques remarques de fond doivent être faites quant à l'amitié dans un modèle OO.

class X {
   int val;
   friend class Y;
};
class Y {
protected:
   X &x;
   // Ok (Y est l'ami de X)
   int f() const {
      return x.val;
   }
public:
   Y(X &x) : x{x} {
   }
};
class Z : public Y {
public:
   Z(X &x) : Y{ x } {
   } // Ok
   int g() const {
      return f(); // Ok
   }
   // illégal (l'amitié n'est pas héritée)
   int h() const {
      return x.val;
   }
};

class X {
   int val;
   friend class Y;
};
class Y {
protected:
   X &x;
public:
   Y(X &x) : x{ x } {
   }
private:
   int f() const {
      return x.val;
   }
   friend class Z;
};
class Z {
   Y &y;
public:
   Z(Y &y) : y{ y } {
   }
   // Ok (Z est amie de Y)
   int g() const {
      return y.f();
   }
   // illégal (Z n'est pas amie de X)
   int h() const {
      return y.x.val;
   }
};

Utiliser sainement l'amitié

L'amitié est la relation ayant le plus fort couplage (plus même que l'héritage public!) dans une approche OO. Sachant cela, pourquoi donc voudrait-on la mettre en application?

En fait, on aura recours à l'amitié lorsque l'impact de ne pas y avoir recours serait pire encore. Par exemple :

• Il arrive qu'un détail d'implémentation d'une classe doive être révélé à un sous-programme ou à une autre classe, souvent pour des raisons techniques
• Sans certains cas, on utilisera une encapsulation dans une méthode pour résoudre le problème, mais il arrivera qu'on ne veuille pas même exposer cette méthode. Pensez à un cas où l'accès direct à un attribut soit requis, par exemple si cet attribut est un pointeur, mais où il serait dangereux de donner publiquement accès à cet attribut. Retourner une copie d'un pointeur donne accès au même objet que si on utilisait le pointeur original, après tout
• Devant révéler un tel détail à un nombre restreint de classes ou de sous-programmes, mais ne voulant pas ouvrir l'accès à ce détail au grand public, on aura recours aux amis

Utiliser l'amitié avec modération peut être moins dommageable que l'alternative, soit offrir un accès public à un attribut ou à une méthode donnant un accès direct, bien que de manière détournée, à un attribut. De manière générale, l'amitié est préférable à une corruption du visage public d'une classe.

La même démarche intellectuelle se pose pour l'accès à une méthode devant rester privée ou protégée, mais pour laquelle un nombre restreint d'autres classes ou de sous-programmes devraient avoir un accès immédiat.

L'amitié est la relation la plus intime que peut entretenir une classe hormis celle résultant de l'exposition publique de ses attributs. Ceci signifie, tel qu'indiqué plus haut dans cette section, que l'amitié est aussi la relation à plus fort couplage que peut entretenir une classe. Sachant cela, tout abus devient malsain.

La manière la plus convenable de percevoir l'amitié est comme extension de l'interface d'une classe. Une classe amie de la classe X devrait être considérée comme faisant partie logiquement de l'interface de X, et il en va de même pour toute fonction amie de X. Par conséquent, les amis d'une classe devraient être insérés dans les mêmes fichiers que cette classe. Les amis doivent être déclarés ensembles et définis ensembles, pour éviter qu'un tiers hostile ne remplace ou ne personnifie l'un sans personnifier l'autre.

Autre exemple : soit une classe X que l'on souhaite instanciable seulement de manière dynamique (avec new). L'un des trucs les plus simples pour y arriver est de déclarer le destructeur de X privé, mais cela pose la bête question « mais comment détruire un X si son destructeur est privé? ». Un truc est d'offrir une autre méthode, par exemple destroy(), qui réaliserait un hara-kiri à l'interne :

class X {
   ~X() = default; // privé
public:
   void destroy() const { delete this; } // hara-kiri
};
int main() {
   // X x; // illégal, destructeur privé
   X *p = new X;
   // delete p; // illégal, destructeur privé
   p->destroy();
}

Cependant, utiliser des pointeurs bruts n'est pas idiomatique en C++ moderne, et on préférerait utiliser des pointeurs intelligents, or utiliser un pointeur de méthode d'instance comme destroy() à titre de Custom Deleter dans un std::unique_ptr est... inconfortable. Par contre, utiliser un objet d'un certain type, ou encore utiliser un pointeur de fonction, est plus simple. Pour un pointeur de fonction :

#include <iostream>
#include <memory>
class X {
   ~X() = default; // privé
public:
   friend void assassin(const X*);
};
void assassin(const X *x) { delete x; }
int main() {
   using namespace std;
   unique_ptr<X, void(*)(const X*)> p{ new X, assassin };
}

... et pour un objet :

#include <iostream>
#include <memory>
class X {
   ~X() = default; // privé
public:
   friend struct Assassin;
};
struct Assassin {
   void operator()(const X *p) const { delete p; }
};
int main() {
   using namespace std;
   unique_ptr<X, Assassin> p{ new X };
}

Amitié et injection de fonctions globales

Une autre utilité directe de la mention friend dans une classe est qu'elle permet d'injecter une définition de fonction globale dans un programme. Pour un exemple concret, imaginons une classe Id qui ne serait modifiable qu'à la construction. Supposons que nous ne souhaitions par exposer la valeur du Id, mais que nous souhaitons qu'il soit possible d'utiliser des Id en tant que clé dans une collection, ce qui requiert de définir operator< pour deux Id.

Une manière simple d'implémenter une ébauche d'une telle classe Id serait :

class Id {
   int val;
public:
   Id(int val) : val{ val } {
   }
   bool operator<(const Id &autre) const {
      return val < autre.val;
   }
   // ...
};

Cette approche repose sur une méthode d'instance. Si notre préférence va au respect des usages, il se peut que nous souhaitions définir les opérateurs relationnels binaires sous forme de fonction globale plutôt que sous forme de méthode d'instance, mais cela implique de donner à cette classe un accès privilégié aux membres privés de Id (en particulier, à son attribut val) :

class Id {
   int val;
public:
   Id(int val) : val{ val } {
   }
   friend inline bool operator<(const Id &a, const Id &b) {
      return a.val < b.val;
   }
   // ...
};

Ceci crée et injecte dans le programme une fonction globale operator<() applicable à deux Id, et capable d'accéder à ses membres protégés et privés. Une technique pour compléter l'offre d'opérateurs relationnels d'inégalité sur la base d'un opérateur < correctement codé est le truc Barton-Nackman, qui utilise l'idiome CRTP et le mot-clé friend pour générer des services sur demande pour une classe :

template <class T>
   class ordonnancement {
      friend bool operator>(const T &a, const T &b) {
         return b < a;
      }
      friend bool operator<=(const T &a, const T &b) {
         return !(b < a);
      }
      friend bool operator>=(const T &a, const T &b) {
         return !(a < b);
      }
   };
class Id : ordonnancement<Id> {
   int val;
public:
   Id(int val) : val{ val } {
   }
   friend inline bool operator<(const Id &a, const Id &b) {
      return a.val < b.val;
   }
   // ... on gagne >, <= et >=
};

... mais ce truc risque de disparaître avec C++ 20 et l'avènement de l'opérateur <=>.

Les amis cachés (Hidden Friends)

La bibliothèque standard utilise beaucoup ce qu'on nomme des hidden friends, soit des fonctions déclarées amies d'une classe mais déclarées de manière telle que le seul mécanisme permettant de les accéder soit l'Argument-Dependent Lookup (ADL). Par exemple, ci-dessous, il n'est pas possible de prendre l'adresse de la fonction operator<<(std::ostream&,const N::X&) ou de l'appeler directement, mais elle est implicitement accessible en présence d'un N::X :

#include <iostream>
namespace N {
   class X {
      friend inline std::ostream &operator<<(std::ostream &os, const X&) {
         return os << "X";
      }
   };
}
int main() {
   using namespace std;
   using N::X;
   X x;
   cout << x;
}

Lectures complémentaires

Quelques liens pour enrichir le propos.

• https://en.cppreference.com/w/cpp/language/friend
• http://www.parashift.com/c++-faq-lite/friends.html
• En 2006, Alan R. Bolton propose une manière d'utiliser sainement l'amitié : https://www.drdobbs.com/friendship-and-the-attorney-client-idiom/184402053
• À propos de la granularité de l'amitié, brève question / réponse proposée par Herb Sutter en 2018 : https://devblogs.microsoft.com/cppblog/qa-fine-grained-friendship/
• Quelques divergences d'implémentation avec friend, relevées par Arthur O'Dwyer en 2019 : https://quuxplusone.github.io/blog/2019/09/10/friend-access-inconsistencies/
• Explications très détaillées par Dawid Pilarski en 2020 : https://blog.panicsoftware.com/friends-and-where-to-find-them/
• À propos des Hidden Friends :
  • http://eel.is/c++draft/hidden.friends
  • Texte d'Anthony Williams en 2019 : https://www.justsoftwaresolutions.co.uk/cplusplus/hidden-friends.html