Questo è un buon approccio per una gerarchia di classi basata su "pImpl" in C ++?

Penso che sia una strategia scadente per fare in modo che Derived_1::Impl derivi da Base::Impl .

Lo scopo principale dell'uso dell'idioma Pimpl è di nascondere i dettagli di implementazione di una classe. Consentendo che Derived_1::Impl derivi da Base::Impl , hai sconfitto lo scopo. Ora, non solo l'implementazione di Base dipende da Base::Impl , l'implementazione di Derived_1 dipende anche da Base::Impl .

Is there a better solution?

Dipende da quali compromessi sono accettabili per te.

Soluzione 1

Rendi le classi Impl totalmente indipendenti. Ciò implicherà che ci saranno due puntatori alle classi Impl - una in Base e un'altra in Derived_N .

class Base {

   protected:
      Base() : pImpl{new Impl()} {}

   private:
      // It's own Impl class and pointer.
      class Impl { };
      std::shared_ptr<Impl> pImpl;

};

class Derived_1 final : public Base {
   public:
      Derived_1() : Base(), pImpl{new Impl()} {}
      void func_1() const;
   private:
      // It's own Impl class and pointer.
      class Impl { };
      std::shared_ptr<Impl> pImpl;
};

Soluzione 2

Esporre le classi solo come maniglie. Non esporre le definizioni e le implementazioni della classe.

File di intestazione pubblico:

struct Handle {unsigned long id;};
struct Derived1_tag {};
struct Derived2_tag {};

Handle constructObject(Derived1_tag tag);
Handle constructObject(Derived2_tag tag);

void deleteObject(Handle h);

void fun(Handle h, Derived1_tag tag);
void bar(Handle h, Derived2_tag tag); 

Ecco l'implementazione rapida

#include <map>

class Base
{
   public:
      virtual ~Base() {}
};

class Derived1 : public Base
{
};

class Derived2 : public Base
{
};

namespace Base_Impl
{
   struct CompareHandle
   {
      bool operator()(Handle h1, Handle h2) const
      {
         return (h1.id < h2.id);
      }
   };

   using ObjectMap = std::map<Handle, Base*, CompareHandle>;

   ObjectMap& getObjectMap()
   {
      static ObjectMap theMap;
      return theMap;
   }

   unsigned long getNextID()
   {
      static unsigned id = 0;
      return ++id;
   }

   Handle getHandle(Base* obj)
   {
      auto id = getNextID();
      Handle h{id};
      getObjectMap()[h] = obj;
      return h;
   }

   Base* getObject(Handle h)
   {
      return getObjectMap()[h];
   }

   template <typename Der>
      Der* getObject(Handle h)
      {
         return dynamic_cast<Der*>(getObject(h));
      }
};

using namespace Base_Impl;

Handle constructObject(Derived1_tag tag)
{
   // Construct an object of type Derived1
   Derived1* obj = new Derived1;

   // Get a handle to the object and return it.
   return getHandle(obj);
}

Handle constructObject(Derived2_tag tag)
{
   // Construct an object of type Derived2
   Derived2* obj = new Derived2;

   // Get a handle to the object and return it.
   return getHandle(obj);
}

void deleteObject(Handle h)
{
   // Get a pointer to Base given the Handle.
   //
   Base* obj = getObject(h);

   // Remove it from the map.
   // Delete the object.
   if ( obj != nullptr )
   {
      getObjectMap().erase(h);
      delete obj;
   }
}

void fun(Handle h, Derived1_tag tag)
{
   // Get a pointer to Derived1 given the Handle.
   Derived1* obj = getObject<Derived1>(h);
   if ( obj == nullptr )
   {
      // Problem.
      // Decide how to deal with it.

      return;
   }

   // Use obj
}

void bar(Handle h, Derived2_tag tag)
{
   Derived2* obj = getObject<Derived2>(h);
   if ( obj == nullptr )
   {
      // Problem.
      // Decide how to deal with it.

      return;
   }

   // Use obj
}

Pro e contro

Con il primo approccio, puoi costruire Derived classi nello stack. Con il secondo approccio, questa non è un'opzione.

Con il primo approccio, devi sostenere il costo di due allocazioni e deallocazioni dinamiche per la costruzione e la distruzione di un Derived nello stack. Se si costruisce e si distrugge un oggetto Derived dall'heap, si incorre nel costo di un'ulteriore allocazione e deallocazione. Con il secondo approccio, devi sostenere solo il costo di un'allocazione dinamica e una deallocazione per ogni oggetto.

Con il primo approccio, hai la possibilità di usare virtual la funzione membro è Base . Con il secondo approccio, questa non è un'opzione.

Il mio suggerimento

Vorrei andare con la prima soluzione in modo da poter utilizzare la gerarchia di classi e le funzioni membro virtual in Base anche se è un po 'più costoso.

L'unico miglioramento che riesco a vedere qui è lasciare che le classi concrete definiscano il campo di implementazione. Se le classi base astratte ne hanno bisogno, possono definire una proprietà astratta che è facile da implementare nelle classi concrete:

Base.h

class Base {
protected:
    class Impl;
    virtual std::shared_ptr<Impl> getImpl() =0;
    ...
};

class Derived_1 final : public Base {
protected:
    class Impl1;
    std::shared_ptr<Impl1> pImpl
    virtual std::shared_ptr<Base::Impl> getImpl();
public:
    Derived_1(...);
    void func_1(...) const;
    ...
};

Base.cpp

class Base::Impl {
public:
    Impl(...) {...}
    ...
};

class Derived_1::Impl1 final : public Base::Impl {
public:
    Impl(...) : Base::Impl(...) {...}
    void func_1(...) {...}
    ...
};

std::shared_ptr<Base::Impl> Derived_1::getImpl() { return pPimpl; }
Derived_1::Derived_1(...) : pPimpl(std::make_shared<Impl1>(...)) {...}
void Derived_1::func_1(...) const { pPimpl->func_1(...); }

Questo sembra essere più sicuro per me. Se hai un grande albero, puoi anche introdurre virtual std::shared_ptr<Impl1> getImpl1() =0 nel mezzo dell'albero.