È un buon posto per usare il modello PIMPL?

Question

Sto lavorando a una libreria che definisce un'interfaccia client per qualche servizio. Sotto il cofano devo convalidare i dati forniti dagli utenti e poi passarlo al processo di "motore" utilizzando classe Connection da un'altra libreria (nota: la classe Connection non è noto agli utenti della nostra biblioteca). Uno dei miei colleghi ha proposto di utilizzare Pimpl:

class Client { 
public: 
    Client(); 
    void sendStuff(const Stuff &stuff) {_pimpl->sendStuff(stuff);} 
    Stuff getStuff(const StuffId &id) {return _pimpl->getStuff(id);} 
private: 
    ClientImpl *_pimpl; 
} 

class ClientImpl { // not exported 
public: 
    void sendStuff(const Stuff &stuff); 
    Stuff getStuff(const StuffId &id); 
private: 
    Connection _connection; 
} 

Tuttavia, trovo molto difficile prova - anche se collego il mio test per qualche implementazione deriso di connessione, non ho un facile accesso ad essa per impostare e convalidare le aspettative. Mi sto perdendo qualcosa, o molto più pulito e la soluzione verificabile utilizza l'interfaccia + fabbrica:

class ClientInterface { 
public: 
    void sendStuff(const Stuff &stuff) = 0; 
    Stuff getStuff(const StuffId &id) = 0; 
} 

class ClientImplementation : public ClientInterface { // not exported 
public: 
    ClientImplementation(Connection *connection); 
    // +implementation of ClientInterface 
} 

class ClientFactory { 
    static ClientInterface *create(); 
} 

Esistono motivi per andare con Pimpl in questa situazione?

Answer 1

GoTW15

GoTW28

Da Herb Sutter. Buoni consigli per iniziare.

Answer 2

AFAIK il solito motivo per utilizzare l'idioma Pimpl è ridurre le dipendenze del tempo di compilazione/collegamento all'implementazione della classe (rimuovendo del tutto i dettagli di implementazione dal file di intestazione pubblico). Un altro motivo potrebbe essere quello di consentire alla classe di cambiare il suo comportamento dinamico (aka il State pattern).

Il secondo non sembra essere il caso qui, e il primo può essere raggiunto con l'eredità + una fabbrica pure. Tuttavia, come hai notato, quest'ultima soluzione è molto più semplice da testare, quindi preferirei questo.

Answer 3

Sì, questo è un buon posto per utilizzare il modello di Pimpl, e sì, sarà difficile per testare come è.

Il problema è che i due concetti si oppongono l'un l'altro:

• Pimpl è di nascondere le dipendenze dal client: questo riduce la compilazione/collegamento in tempo ed è meglio dal punto di vista della stabilità ABI.
• Unit Testing è di solito circa un intervento chirurgico nelle dipendenze (uso di mock up, per esempio)

Tuttavia, ciò non significa che si dovrebbe sacrificare uno per l'altro. Significa semplicemente che dovresti adattare il tuo codice.

Ora, che cosa se Connection è stato realizzato con lo stesso linguaggio?

class Connection 
{ 
private: 
    ConnectionImpl* mImpl; 
}; 

e consegnati attraverso una fabbrica:

// Production code: 

Client client = factory.GetClient(); 

// Test code: 
MyTestConnectionImpl impl; 
Client client = factory.GetClient(impl); 

In questo modo, è possibile accedere al nitty particolari granulosi del test implementano di connessione durante il test del client senza esporre l'attuazione al cliente o rompere l'ABI .