Qual è il punto del modello PImpl mentre possiamo usare l'interfaccia per lo stesso scopo in C ++?

Vedo un sacco di codice sorgente che usa il linguaggio PImpl in C ++. Presumo che il suo scopo sia quello di nascondere i dati / tipo / implementazione privati, in modo che possa rimuovere la dipendenza e quindi ridurre il tempo di compilazione e l'intestazione includa il problema.

Ma anche le classi interface / pure-abstract in C ++ hanno questa capacità, possono anche essere usate per nascondere dati / tipo / implementazione. E per consentire al chiamante di vedere semplicemente l'interfaccia durante la creazione di un oggetto, possiamo dichiarare un metodo factory nell'intestazione dell'interfaccia.

Il confronto è:

1. Costo :

   Il costo dell'interfaccia è inferiore, poiché non è nemmeno necessario ripetere l'implementazione della funzione wrapper pubblica void Bar::doWork() { return m_impl->doWork(); }, è sufficiente definire la firma nell'interfaccia.

2. Ben capito :

   La tecnologia dell'interfaccia è meglio compresa da ogni sviluppatore C ++.

3. Prestazioni :

   Interfaccia modo prestazioni non peggiori del linguaggio PImpl, sia un ulteriore accesso alla memoria. Presumo che la performance sia la stessa.

Di seguito è riportato lo pseudocodice per illustrare la mia domanda:

// Forward declaration can help you avoid include BarImpl header, and those included in BarImpl header.
class BarImpl;
class Bar
{
public:
    // public functions
    void doWork();
private:
    // You don't need to compile Bar.cpp after changing the implementation in BarImpl.cpp
    BarImpl* m_impl;
};

Lo stesso scopo può essere implementato utilizzando l'interfaccia:

// Bar.h
class IBar
{
public:
    virtual ~IBar(){}
    // public functions
    virtual void doWork() = 0;
};

// to only expose the interface instead of class name to caller
IBar* createObject();

Allora, qual è il punto di PImpl?

Innanzitutto, PImpl viene solitamente utilizzato per le classi non polimorfiche. E quando una classe polimorfica ha PImpl, di solito rimane polimorfica, ovvero implementa ancora interfacce e ignora i metodi virtuali dalla classe base e così via. L'implementazione più semplice di PImpl non è l' interfaccia, è una semplice classe che contiene direttamente i membri!

Esistono tre motivi per utilizzare PImpl:

1. Rendere l' interfaccia binaria (ABI) indipendente dai membri privati. È possibile aggiornare una libreria condivisa senza ricompilare il codice dipendente, ma solo finché l' interfaccia binaria rimane la stessa. Ora quasi tutte le modifiche all'intestazione, ad eccezione dell'aggiunta di una funzione non membro e dell'aggiunta di una funzione membro non virtuale, cambiano l'ABI. Il linguaggio PImpl sposta la definizione dei membri privati ​​nella fonte e disaccoppia l'ABI dalla loro definizione. Vedi Problema all'interfaccia binaria fragile

2. Quando viene modificata un'intestazione, è necessario ricompilare tutte le origini inclusa quella. E la compilazione C ++ è piuttosto lenta. Quindi, spostando le definizioni dei membri privati ​​nella fonte, il linguaggio PImpl riduce il tempo di compilazione, poiché è necessario estrarre meno dipendenze nell'intestazione e ridurre i tempi di compilazione dopo le modifiche ancora di più poiché le persone a carico non devono essere ricompilate (ok, questo vale anche per l'interfaccia + funzione di fabbrica con classe di calcestruzzo nascosta).

3. Per molte classi in C ++ la sicurezza è una proprietà importante. Spesso è necessario comporre più classi in una in modo tale che se durante l'operazione su più di un membro genera, nessuno dei membri viene modificato o si ha un'operazione che lascerà il membro in stato incoerente se viene generato e è necessario che l'oggetto contenitore rimanga coerente. In tal caso, si implementa l'operazione creando una nuova istanza di PImpl e si scambiano quando l'operazione ha esito positivo.

In realtà l'interfaccia può essere utilizzata anche solo per nascondere l'implementazione, ma presenta i seguenti svantaggi:

1. L'aggiunta di un metodo non virtuale non interrompe l'ABI, ma l'aggiunta di un metodo virtuale lo fa. Pertanto le interfacce non consentono affatto di aggiungere metodi, lo fa PImpl.

2. Inteface può essere utilizzato solo tramite puntatore / riferimento, quindi l'utente deve occuparsi della corretta gestione delle risorse. D'altra parte le classi che usano PImpl sono ancora tipi di valore e gestiscono le risorse internamente.

3. L'implementazione nascosta non può essere ereditata, la classe con PImpl può.

E ovviamente l'interfaccia non aiuta con la sicurezza delle eccezioni. Per questo è necessario il riferimento indiretto all'interno della classe.

Voglio solo affrontare il tuo punto di esibizione. Se usi un'interfaccia, hai necessariamente creato funzioni virtuali che NON SARANNO sottolineate dall'ottimizzatore del compilatore. Le funzioni PIMPL possono (e probabilmente lo saranno, perché sono così brevi) essere incorporate (forse più di una volta se anche la funzione IMPL è piccola). Una chiamata di funzione virtuale non può essere ottimizzata se non si utilizzano ottimizzazioni di analisi del programma completo che richiedono molto tempo.

Se la tua classe PIMPL non viene utilizzata in modo critico per le prestazioni, questo punto non ha molta importanza, ma il tuo presupposto che le prestazioni siano le stesse vale solo in alcune situazioni, non in tutte.

Questa pagina risponde alla tua domanda. Molte persone sono d'accordo con la tua affermazione. L'uso di Pimpl presenta i seguenti vantaggi rispetto ai campi / membri privati.

1. La modifica delle variabili dei membri privati ​​di una classe non richiede la ricompilazione delle classi che dipendono da essa, quindi i tempi sono più rapidi e il FragileBinaryInterfaceProblem è ridotto.
2. Il file di intestazione non ha bisogno di #includere le classi utilizzate 'per valore' nelle variabili dei membri privati, quindi i tempi di compilazione sono più veloci.

Il linguaggio Pimpl è un'ottimizzazione del tempo di compilazione, una tecnica di rottura delle dipendenze. Riduce i file di intestazione di grandi dimensioni. Riduce l'intestazione solo all'interfaccia pubblica. La lunghezza dell'intestazione è importante in C ++ quando pensi a come funziona. #include concatena efficacemente il file header al file sorgente, quindi tieni presente che le unità C ++ pre-elaborate possono essere molto grandi. L'uso di Pimpl può migliorare i tempi di compilazione.

Esistono altre migliori tecniche di interruzione della dipendenza, che comportano il miglioramento del design. Cosa rappresentano i metodi privati? Qual è la singola responsabilità? Dovrebbero essere un'altra classe?