Question

假设有一个名为（包括命名空间）的第三方类other::OtherClass。

这是头文件。

class MyClass {
  public:
    ...
  private:
    other::OtherClass other_class_;
    ...
}

如果此头文件是在生产中发布的，是否会将此实现暴露给客户端？

另一方面，在公共界面中使用第三方类是否是个好主意？（请注意，第二个示例不一定将该类保存到私有成员中。）

class MyClass {
  public:
    MyClass(const other::OtherClass& other_class);
    ...
  private:
    ...
}

在第一个示例中，客户端必须知道other::OtherClass的大小并包含头文件。在第二个示例中，客户端需要能够构造other::OtherClass，如果未提供工厂，可能需要头文件。

上述任何一个例子都有很好的借口吗？

如果这几乎不是一个好主意，那么设计上述类的常用方法是什么？

Answer 1

供应商必须通过他们提供的头文件向客户公开某些数量的库。

话虽如此，有一些技术可以隐藏实现中的数据和功能。其中一种比较常见的技术是提供公共代理类和工厂函数，这些函数只向客户端公开最少量的公共功能。

关于第二个问题，最好在标题中使用第三方类型的引用和指针，因为您可以在头文件中转发声明类型：

class other::OtherClass;

需要实际包含第三方头文件。这不会将任何第三方详细信息暴露给您的库的客户端。

Answer 2

使用公共标题界面，您应该做出最少量的承诺并尽可能少地公开的详细信息。其他一切都应该是实施细节。

即使您不希望将来能够更换供应商，我也看不出将您的界面与第三方类紧密结合的任何理由。

设计接口/ impl时需要考虑很多事情。你可以参考design patterns book