0

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.

5
  • "until today i had a static library with no interface for it, my other apps just linked to it and used whatever they needed." - did this lib provide C-style functions for usage, or C++ classes?
    – Doc Brown
    Aug 6 at 5:14
  • The client (me) just used whatever class he needed Aug 6 at 5:24
  • Just repeating what you already wrote in your question is not clarifying things. Can you please edit an example how clients used classes from your static lib "with no interfaces"? I mean, to use a C++ class from a lib, a client usually needs include a class definition. So where does the client get this definition from if not by some header (=interface) file of your lib?
    – Doc Brown
    Aug 6 at 5:51
  • the lib has a lot of "internal headers" and source files , nothing like real external interface, so you can just create whatever class you need, i dont like it ,because it is not the proper way to use a library so i built one simple interface for the usage i want to expose, any way user can still do what ever he wants Aug 6 at 6:57
  • 1
    Ok, I guess what you are trying to ask, let me reword your question a bit, so it becomes clearer (and maybe more answers).
    – Doc Brown
    Aug 6 at 11:13
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).

2
  • Which implementation file? Should i have Imylib.cpp also? Aug 6 at 5:25
  • 1
    @user3717741, the file with the implementation of MyLib for example. Aug 6 at 8:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.