How to expose C++ static library interface, extending Pimpl to an abstract interface

Question

Until today I had a static C++ library with no separation between the public interface and internal headers. My other apps just linked to it, included the required headers, and used whatever they needed.

I want to change this, so I created something like

//myLib.h class myLib { void doSomthing(); InterfaceA *getInterfaceA(); void doSomethingElse(); private:; myLibImpl* impl_ } //myLibImpl.cpp { //using the internals of the lib } 

so the user of MyLib is not exposed to compilation changes in the real library source code.

The thing is I read that there is an alternative way to do it using interface and factory method.

I have read many SO articles and other design patterns/refactoring articles, but just cant understand how it is keeping the clients free from changes in the lib.

What I have seen is something like this, not sure about it:

class IMyLib { virtual void doSomthing(); virtual InterfaceA *getInterfaceA(); // hope this not confusing anyone ,can ignore it virtual void doSomethingElse(); } //in other files: class MyLib: public IMyLib { void doSomthing() {using my real lib sources}; InterfaceA *getInterfaceA() {using my real lib sources}; void doSomethingElse(){using my real lib sources}; } 

My confusion starts here , somewhere someone should write something like

IMyLib* createImpl() { return new MyLib; // yes yes, naked new , c++98 poor me. }

and this line of code knows Mylib, hence will be affected from changes in the real lib source files.

I have read about "abstract factory" and "factory method" and static functions in the interface but they all causing the client app to be affected from changes in the library source files, not like in the pimpl ideion I initially used.

I would prefer to use such an external interface because I think it is easier to understand, to debug and to replace for a client test.

I dont have any need for polymorphism, I dont care about any ABI stability, and I dont use any dynamic linking.

I am sure I am missing something.

Answer 1

The idea is that you'd have, in the header:

IMyLib * CreateInstance(); 

And then in the implementation file have the body which references the concrete class. So it's equally separated as the pImpl version.

Is it better? IMO, mainly if you have the possibility of multiple different implementations in the future (mocking, for instance, or versions that use different backends). If there's only ever going to be one, this is similar to pImpl with the additional overhead of virtual calls (although whether that overhead matters depends on what the library is doing).