Является ли это хорошим местом для использования шаблона PIMPL?

Question

Я работаю над библиотекой, которая определяет клиентский интерфейс для некоторой службы. Под капотом я должен проверить данные, предоставленные пользователями, а затем передать их процессу «двигатель», используя класс Connection из другой библиотеки (обратите внимание: класс Connection не известен пользователям нашей библиотеки). Один из моих коллег предложил использовать 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; 
} 

Однако, я считаю, это очень тяжело протестировать - даже если я свяжу свои тесты в какой-то издевался реализации Connection, не имеют легкий доступ к нему, чтобы установить и утверждать ожидания. Могу ли я что-то отсутствует, или значительно чище и проверяемым решение использует интерфейс + завод:

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(); 
} 

Существуют ли какие-либо причины, чтобы пойти с Pimpl в этой ситуации?

Answer 1

GoTW15

GoTW28

От Herb Sutter. Хорошие указания, чтобы вы начали.

Answer 2

AFAIK обычная причина использования идиомы Pimpl заключается в сокращении зависимостей времени компиляции/ссылки до реализации класса (путем полного удаления сведений о реализации из общего файла заголовка). Другая причина может заключаться в том, чтобы позволить классу динамически изменять свое поведение (ака State pattern).

Второе, похоже, не так, и первое может быть достигнуто с наследованием + фабрикой. Однако, как вы заметили, последнее решение намного проще для модульного тестирования, поэтому я бы предпочел это.

Answer 3

Да, это хорошее место для использования рисунка Pimpl, и да, это будет сложно проверить, как есть.

Проблема состоит в том, что эти две концепции противостоят друг другу:

• Pimpl является прятать зависимости от клиента: это уменьшает время компиляции/ссылок и лучше с точки стабильности ABI зрения.
• модульное тестирование, как правило, о хирургическом вмешательстве в зависимости (использование макетов, например)

Однако, это не означает, что вы должны принести в жертву одну за другой. Это просто означает, что вы должны адаптировать свой код.

Теперь, если бы Connection был выполнен с одинаковой идиомой?

class Connection 
{ 
private: 
    ConnectionImpl* mImpl; 
}; 

и избавили через Factory:

// Production code: 

Client client = factory.GetClient(); 

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

Таким образом, вы можете получить доступ к вшивому песчаным подробностям теста осуществления связи во время тестирования клиента, не подвергая реализации клиента или нарушения ABI ,