C++ interface inheritance with a Factory

Question

I'm using a library which have an interface for a certain functionality, and a few implementation of the functionality. The library also provides a Factory object that instantiates the correct functionality's implementation.

I need to extend a functionality in question by adding new methods to the object, and I wanted to do this by creating a new interface which inherits from the library's interface and roll my own implementations.

For example :

class IFromLibrary
{
  virtual void LibraryMethod(void) = 0;
}

class IMyInterface : public IFromLibrary
{
  virtual void MyMethod(void) = 0;
  int SomeValue;
}

class TMyImplementation : public IMyInterface
{
  void LibraryMethod(void) { ... }
  void MyMethod(void) { ... }
}

The problem I'm facing is with the creation of an instance of TMyImplementation. Like I said, the library hides the constructors of the implementations as private members and uses Factory static methods to construct the objects.

Example :

static IFromLibrary * createFromLibrary(int whatever) { ... }

Since it's the paradigm of the library, I'm trying to do it as well by creating my own create in my implementation class :

static IMyInterface * createMyImplementation(int whatever) { ... }

The problem I have is that I'd wish that my newly instantiated object would be constructed using the values provided by the library's Factory :

static IMyInterface * createMyImplementation(int whatever)
{
  IMyInterface * newObject = createFromLibrary(whatever); // this doesn't compile, evidently.
  newObject->SomeValue = SomeOtherValue; // init the parts of the object that belong to my interface
}

I'm trying to avoid the adapter pattern (i.e. wrapping a IFromLibrary pointer inside my TMyImplementation class and forward all the method calls that are inherited from IFromLibrary­). That would indeed work, but from my point of view, I find it strange, architecturally speaking, that I simultaneously inherit from and wrap a class. I also want to avoid all that forwarding boiler plate code, if at all possible.

Can this be done in any way?

EDIT :

• Added the fact that the private constructors are for the implementations only (sorry @NirFriedman for the confusion).
• Specified why I want (if possible) to avoid the Adapter pattern (thanks @immibis for the pattern name).

Answer 1

You can use the decorator pattern (I said "adapter pattern" before incorrectly - they are quite similar though) - have your TMyImplementation object delegate LibraryMethod to an IFromLibrary object that you got from the library:

class TMyImplementation : public IMyInterface
{
    IFromLibrary *base;
public:
    TMyImplementation(IFromLibrary *base) : base(base) {}
    ~TMyImplementation() {delete base;} // ideally you would use a unique_ptr instead

   void LibraryMethod() {base->LibraryMethod();}
   void MyMethod() {...}
};

Then to create a TMyImplementation you might use new TMyImplementation(createFromLibrary(whatever)).

(Note that patterns are merely starting points for designs, not rules to be strictly followed! For example depending on your design you could move the createFromLibrary call inside the constructor)

Answer 2

It would be great if you could find implementation of "createFromLibrary" and use it in your "createMyImplementation", if it's not possible:

static IMyInterface * createMyImplementation(int whatever)
{
    IFromLibrary* newLibraryObject = createFromLibrary(whatever);
    IMyInterface* newObject = (IMyInterface*)malloc(sizeof(IMyInterface));
    memcpy(newObject, newLibraryObject, sizeof(IFromLibrary));
    newObject->SomeValue = SomeOtherValue;
    return newObject;
}

It is not guaranteed to work, if the library keeps the trace of it's objects, this way it will loose connection with "newObject" that can lead to undefined behavior.

If your library has something like "ReleaseFromLibrary(IFromLibrary* pObj)" try to call it when you finished with "newObject" or "newLibraryObject" or both! (any of them can lead to undefined behavior).

Anyway I don't like this kind of solutions, but nothing better came to my mind!