views:

446

answers:

2

In short: what is the best way to design and implement a factory+plugin mechanism, so that plugins can replace objects in the main application.

We have a code base from which we build our applications. The code base is fine for 70-95% of the applications, meaning that in each new application we need to change 5-30% of the default behavior (add new features, change default logic, add GUI, etc.).

The implementation is plugin-based: the code base is built into an EXE and DLLs, and when the main EXE is running we load a DLL which adds the required functionality.

Currently each plugin exposes the following function:

PluginInterface* PluginInit()
{
    return new MyCustomizedPluginInterface();
}

Where PluginInterface is defined as:

class PluginInterface {
public:
    virtual SomeClass1* customizedSomeClass1() = 0;
    virtual SomeClass2* customizedSomeClass2() = 0;
};

And SomeClass1/SomeClass2 have some default behavior, but can be overridden and changed by the plugin.

The current implementation makes it hard for adding new customized classes. We would like to replace every class in the main application from the plugin, so it makes sense to use object factories.

One SDK that I know uses the following technique:

PluginInterface* PluginInit(GodObject* godObject)
{
    FactoryForSomeClasses* factoryForSomeClasses = 
        godObject->factoryForSomeClasses();
    factoryForSomeClasses->setSomeClass1Creator( MyCustomizedSomeClass1::create); // create is a static creator function.
    factoryForSomeClasses->setSomeClass2Creator( MyCustomizedSomeClass2::create);
}

I wonder if there are any alternatives to this approach.

How would you recommend designing and implementing a plugin system/factory like I just described?

+1  A: 

Did you look at CodeProject examples for plugins frameworks? https://secure.codeproject.com/KB/DLL/plugin.aspx http://www.codeproject.com/KB/library/dynobj.aspx

Baget
+1  A: 

There was an article a while back in Doctor Dobb's that discussed this exact problem. Here is a link to the article in question.

As an aside you may want to stick with a straight C interface for the plugins to your project. That way you can link code written in almost any language into your framework with minimal hassle. While C++ is nice, being able to leverage more than what exists in C++, like the incredible frameworks that exist in Java and Python lands, could prove beneficial in the long run.