这是使用 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

据我所知，使用 Pimpl 习惯用法的通常原因是减少对类实现的编译/链接时间依赖性（通过从公共头文件中完全删除实现细节）。另一个原因可能是使类能够动态更改其行为（也称为状态模式）。

这里第二个似乎不是这样，第一个也可以通过继承+工厂来实现。然而，正如您所指出的，后一个解决方案更容易进行单元测试，所以我更喜欢这个。

Answer 2

GoTW15

GoTW28

来自赫伯·萨特。很好的指导，可以帮助您入门。

Answer 3

是的，这是使用 Pimpl 模式的好地方，是的，按原样测试会很困难。

问题是这两个概念相互对立：

• Pimpl 是关于向客户端隐藏依赖项：这减少了编译/链接时间，并且从 ABI 稳定性的角度来看更好。
• 单元测试通常是关于对依赖项进行外科手术干预（例如使用模型），

但是，这并不意味着您应该牺牲一个来换取另一个。这仅仅意味着您应该调整您的代码。

现在，如果 Connection 是用相同的习惯用法实现的呢？

class Connection
{
private:
  ConnectionImpl* mImpl;
};

并通过工厂交付：

// Production code:

Client client = factory.GetClient();

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

这样，您可以在测试客户端时访问连接测试实现的具体细节，而无需向客户端公开实现或破坏 ABI。