C ++插件系统，其中插件从基类继承

Question

I am trying to add a plugin capability to my C++ codebase. The difficulty arises because the plugins need to contain plumbing the plugin writer shouldn't be aware of (thus keeping the include file simple). So, this is the setup:

"PluginBase.h". This is the class the plugin would inherit from.

class PluginBase {
  virtual void PluginProcess() = 0; // the plugin-specific capability 
};

"PluginPlumbing.h". The class that contains the plumbing.

class PluginPlumbing : public PluginBase {
  void PlumbingFunction() {
    // Some stuff
    PluginProcess();
    // Some more stuff
  }
};

The outer framework code would (by loading the DLL/so of the plugin) acquire a pointer to a PluginPlumbing class instance, and then call PlumbingFunction() on it.

However, the conundrum I have is, I can't just upcast a PluginBase pointer I get from the DLL/so to a PluginPlumbing pointer as it clearly doesn't actually inherit from PluginPlumbing. And I can't have the plugin inherit from PluginPlumbing, because then I'm back at square one of exposing the plumbing to the plugin writer.

The only solution I can imagine is that instead of nicely inheriting, the PluginBase and the PluginPlumbing are entirely separate classes. The PluginBase would be instantiated by the DLL/so, and the PluginPlumbing instance would be instantiated by the framework, and handed that PluginBase pointer so it can make the plumbing calls. Is that the only solution to go about it?

Answer 1

If you want to expose some functionality from your plugins to external software you definitely have to provide some interface for that.

In your example you provided PluginBase interface with PluginProcess() function, so, any other user of your PluginBase interface can call it without having to care about its implementation.

If you need another interface with another method - do it the same way.

class PluginPlumbing {
public:
    virtual void PlumbingFunction() = 0;
};

And hide the implementation in your DLL implementation:

class PluginPlumbingImpl : public PluginPlumbing {
public:
    void PlumbingFunction() override {
       // do the stuff
    }
}

If it needs additional parameters - also pass it as abstract interface classes or POD structures. You should also have some declaration for your plugin function which will create exact instances for your interface implementations (which should be accessible by users of your plugins).

To summarize this, you should have something like that:

// myplugininterface.h
// this header will be exposed to plugin implementors and
// plugin consumers

class IMyPluginClass1 {
public:
    virtual void func1() = 0;
    virtual void func2() = 0;
}

// another interface, ties together other functionality
class IMyPluginClass2 {
public:
    virtual void func1() = 0;
    // you can even pass around your interface classes
    virtual void doSomethingWithAnotherObject(IMyPluginClass1 *obj) = 0;

    // or use "factory" methods to create objects
    virtual IMyPluginClass1 *createObject() = 0;
}

// this is functions implemented by a plugins, they should create
// instances for your plugin objects
// you could do them as a static methods of your classes if you don't
// plan to expose that as C compatible plugins
IMyPluginClass1 *createObject1();
IMyPluginClass2 *createObject2();


// mycoolplugin.cpp
// specific implementation of your plugin, you or someone else
// compile this to plugin DLL

#include "myplugininterface.h"

class IMyPluginClass1Impl : public IMyPluginClass1 {
public:
    IMyPluginClass1Impl() :
        myMyValue(100500)
    {}

    void func1() override {
        // implement
    }
    void func2() override {
        // implement
    }
private:
    // you can have any private or even public members in your implementation
    int mMyValue;
};

class IMyPluginClass2Impl : public IMyPluginClass2 {
public:
    void func1() override {
        // implement
    }

    void doSomethingWithAnotherObject(IMyPluginClass1 *obj) override {
        // implement
        // but don't assume you can cast IMyPluginClass1 to
        // something specific, because it might be not yours implementation
        // it depends on how carefully you design your interfaces and
        // explain to plugin writers what is allowed and what is not
    }

    IMyPluginClass1 *createObject() {
        // be careful with that, in that case you MUST declare
        // virtual destructor as a part of your interface class
        return new IMyPluginClass1Impl();
    }
};

IMyPluginClass1 *createObject1() {
    return new IMyPluginClass1Impl();
}
IMyPluginClass2 *createObject2() {
    return new IMyPluginClass2Impl();
}

And users of your plugin can use it only by including myplugininterface.h and obtaining addresses of create functions (this is platform dependent).

Keep in mind, that if you return instances created by new and allow users of your plugins to delete objects created like that - you must declare virtual destructor for your interface classes.

This is a general approach. It has some pitfalls when you have hierarchy for your plugin objects, you cant share common implementation for your abstract classes without putting some additional effort (assuming you don't want to have copypasta)