Question

Suppose there’s a third party class named (including namespace) other::OtherClass.

And this is the header file.

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

If this header file was shipped in production, would this be considered exposing the implementation to the client?

On the other hand, is it a good idea or not to use a third party class in a public interface? (Note that this second example doesn’t necessarily save that class into a private member.)

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

In the first example, the client has to know the size of other::OtherClass and include the header file. In the second example, the client needs to be able to construct other::OtherClass which also might need the header file if a factory was not provided.

Are there good excuses in doing any of the examples above?

If this is almost never a good idea, what is the usual way to design classes like above?

Answer 1

Vendors have to expose some amount of their library to clients through the header files they provide.

That being said, there are techniques for hiding data and functions within an implementation. One of the more common techniques is to provide public proxy classes and factory functions, which expose only a mimimal amount of public functionality to clients.

As to your second question, it’s better to use references and pointers to the third-party types in your headers, since you can forward-declare the types within your header file as:

class other::OtherClass;

within needing to actually include the third-party header files. This does not expose any of the third-party details to clients of your libraries.