Risposta.

Il pattern progettuale PImpl (Pointer to Implementation), conosciuto anche come Opaque Pointer, è nato come un mezzo per separare l'interfaccia dall'implementazione di una classe in C++. Questo è particolarmente importante per garantire la compatibilità dell'interfaccia binaria (ABI), accelerare la compilazione e nascondere i dettagli di implementazione dall'utente della classe.

Storia della questione.

In molti progetti C++, è necessario modificare le implementazioni delle classi senza cambiare l'interfaccia pubblica e senza ricompilare i client di queste classi. Il problema è che qualsiasi modifica ai file di intestazione richiede la ricompilazione di tutti i moduli dipendenti, il che può essere estremamente costoso su grandi basi di codice. PImpl consente di ridurre al minimo la ricompilazione e offre una migliore incapsulazione.

Problema.

Il modo standard di definire una classe con membri privati nel file di intestazione richiede la conoscenza di tutti questi membri durante la compilazione. Quando si espandono o modificano, è necessario ricompilare tutti i file che includono quella intestazione. Inoltre, questo svela i dettagli dell'implementazione / struttura del cliente, potenzialmente influenzando negativamente la sicurezza e l'integrità architetturale.

Soluzione.

PImpl realizza l'oscuramento dell'implementazione tramite l'uso di un puntatore a una struttura di implementazione forward-declarata (Impl struct/class), definita nel cpp. Questo consente di cambiare l'implementazione senza toccare l'interfaccia.

Esempio di codice:

// Widget.h
class Widget {
public:
    Widget();
    ~Widget();
    void doSomething();
private:
    struct Impl;
    Impl* pimpl; // puntatore opaco
};

// Widget.cpp
#include "Widget.h"
struct Widget::Impl {
    int secret;
};

Widget::Widget() : pimpl(new Impl{42}) {} // segretezza all'interno
Widget::~Widget() { delete pimpl; }
void Widget::doSomething() { pimpl->secret += 1; }

Caratteristiche chiave:

Oscuramento dell'implementazione (incapsulamento, riduzione delle dipendenze).
Stabilità dell'ABI (l'implementazione può cambiare senza ricompilazione dei client).
Miglioramento dei tempi di compilazione dei grandi progetti.

Domande trabocchetto.

Si può usare std::unique_ptr invece di un puntatore grezzo in PImpl?

Sì, l'approccio moderno e sicuro è utilizzare std::unique_ptr (o std::shared_ptr, se è necessario un possesso condiviso). Questo consente di gestire correttamente la memoria senza dover scrivere esplicitamente il distruttore / operatore di copia per un puntatore grezzo:

private:
    std::unique_ptr<Impl> pimpl;

Si può rendere una classe con PImpl spostabile, ma non copiabile?

Sì, se fornisci un costruttore / operatore di move, ma rimuovi il costruttore di copia. Ad esempio:

Widget(Widget&&) noexcept = default;
Widget& operator=(Widget&&) noexcept = default;
Widget(const Widget&) = delete;
Widget& operator=(const Widget&) = delete;

C'è un sovraccarico di prestazioni nell'uso di PImpl?

Sì, a causa della dereferenziazione del puntatore e dell'allocazione dinamica aggiuntiva della memoria (heap allocation). Per strutture critiche alle prestazioni, questo può essere un notevole svantaggio.

Errori comuni e anti-pattern

Non implementare un distruttore corretto, portando a perdite di memoria.
Implementare male la copia (doppio delete, shallow copy).
Utilizzare naked-pointer senza RAII (meglio usare std::unique_ptr).
Abusare di PImpl per piccole classi senza reale necessità.

Esempio dalla vita reale

Caso negativo

Una grande azienda ha implementato PImpl per tutte le classi, anche per semplici strutture dati, portando a un notevole rallentamento delle operazioni semplici a causa della continua dereferenziazione dei puntatori.

Pro:

Facile modifica dell'implementazione senza ricompilazione dei client.
Completo oscuramento dell'implementazione.

Contro:

Perdite di prestazioni.
Complessità eccessiva del codice.

Caso positivo

In un progetto con una libreria di interfaccia utente di lunga durata, PImpl è stato applicato solo a widget complessi con una struttura interna spesso in cambiamento, mantenendo stabile l'ABI per i clienti esterni.