Quand dois-je utiliser l'héritage privé C++ ?

Question

Contrairement à l'héritage protégé, l'héritage privé C++ a trouvé sa place dans le courant dominant du développement C++. Cependant, je n'ai toujours pas trouvé une bonne utilisation pour lui.

Quand l'utilisez-vous ?

Answer 1

Je l'utilise tout le temps. Voici quelques exemples qui me viennent à l'esprit :

• Lorsque je veux exposer une partie mais pas la totalité de l'interface d'une classe de base. L'héritage public serait un mensonge, car Substituabilité de Liskov est cassé, alors que la composition impliquerait d'écrire un tas de fonctions de transfert.
• Lorsque je veux dériver d'une classe concrète sans destructeur virtuel. L'héritage public inviterait les clients à supprimer par le biais d'un pointeur vers la base, invoquant un comportement non défini.

Un exemple typique est la dérivation privée d'un conteneur STL :

class MyVector : private vector<int>
{
public:
    // Using declarations expose the few functions my clients need 
    // without a load of forwarding functions. 
    using vector<int>::push_back;
    // etc...  
};

• Lors de la mise en œuvre du modèle d'adaptation, le fait d'hériter en privé de la classe Adapted évite d'avoir à transférer vers une instance fermée.
• Pour mettre en œuvre un interface privée . Ce problème se pose souvent avec le modèle de l'observateur. Typiquement, ma classe Observer, MyClass dit, s'abonne lui-même avec un certain Sujet. Ensuite, seule MyClass a besoin de faire la conversion MyClass -> Observer. Le reste du système n'a pas besoin de le savoir, donc l'héritage privé est indiqué.

Answer 2

Note après l'acceptation de la réponse : Il ne s'agit PAS d'une réponse complète. Lisez d'autres réponses comme aquí (sur le plan conceptuel) et aquí (à la fois théoriques et pratiques) si la question vous intéresse. Il s'agit simplement d'un tour de passe-passe qui peut être réalisé avec l'héritage privé. Bien que ce soit fantaisie ce n'est pas la réponse à la question.

Outre l'utilisation de base de l'héritage privé présenté dans la FAQ C++ (dont le lien figure dans les commentaires d'autres personnes), vous pouvez utiliser une combinaison d'héritage privé et virtuel pour joint une classe (dans la terminologie .NET) ou pour faire d'une classe final (dans la terminologie Java). Ce n'est pas une utilisation courante, mais j'ai quand même trouvé cela intéressant :

class ClassSealer {
private:
   friend class Sealed;
   ClassSealer() {}
};
class Sealed : private virtual ClassSealer
{ 
   // ...
};
class FailsToDerive : public Sealed
{
   // Cannot be instantiated
};

Scellé peut être instancié. Il dérive de ClassSealer et peut appeler le constructeur privé directement puisqu'il s'agit d'un ami.

FailsToDerive ne compilera pas car il doit appeler la fonction ClassSealer directement (exigence de l'héritage virtuel), mais il ne peut pas le faire car il est privé dans la classe Scellé et dans ce cas FailsToDerive n'est pas un ami de ClassSealer .

---

EDIT

Il a été mentionné dans les commentaires que cela ne pouvait pas être rendu générique à ce moment-là en utilisant le CRTP. La norme C++11 supprime cette limitation en fournissant une syntaxe différente pour les arguments de template :

template <typename T>
class Seal {
   friend T;          // not: friend class T!!!
   Seal() {}
};
class Sealed : private virtual Seal<Sealed> // ...

Bien sûr, tout cela est discutable, puisque C++11 fournit une fonction final mot-clé contextuel dans ce but précis :

class Sealed final // ...

Answer 3

L'utilisation canonique de l'héritage privé est la relation "implémenté en termes de" (merci à Scott Meyers's 'Effective C++' pour cette formulation). En d'autres termes, l'interface externe de la classe héritière n'a aucune relation (visible) avec la classe héritée, mais elle l'utilise en interne pour implémenter sa fonctionnalité.

Answer 4

Une utilisation utile de l'héritage privé est lorsque vous avez une classe qui implémente une interface, qui est ensuite enregistrée avec un autre objet. Vous rendez cette interface privée afin que la classe elle-même doive s'enregistrer et que seul l'objet spécifique avec lequel elle est enregistrée puisse utiliser ces fonctions.

Par exemple :

class FooInterface
{
public:
    virtual void DoSomething() = 0;
};

class FooUser
{
public:
    bool RegisterFooInterface(FooInterface* aInterface);
};

class FooImplementer : private FooInterface
{
public:
    explicit FooImplementer(FooUser& aUser)
    {
        aUser.RegisterFooInterface(this);
    }
private:
    virtual void DoSomething() { ... }
};

Par conséquent, la classe FooUser peut appeler les méthodes privées de FooImplementer par le biais de l'interface FooInterface, alors que les autres classes externes ne le peuvent pas. Il s'agit d'un excellent modèle pour gérer les rappels spécifiques qui sont définis comme des interfaces.

Answer 5

Je pense que la section critique de la FAQ C++ Lite es:

Une utilisation légitime et à long terme de l'héritage privé est lorsque vous voulez construire une classe Fred qui utilise du code dans une classe Wilma, et que le code de la classe Wilma doit invoquer des fonctions membres de votre nouvelle classe Fred. Dans ce cas, Fred appelle des fonctions non virtuelles dans Wilma, et Wilma appelle (généralement des fonctions virtuelles pures) dans elle-même, qui sont surchargées par Fred. Cela serait beaucoup plus difficile à faire avec la composition.

En cas de doute, il faut préférer la composition à l'héritage privé.