tags:

views:

36

answers:

4

I have an application that's suppose to be realized in plugin pattern.
Plugins are located in dll files and I'm loading them on the fly, depending on the parameter given from a user via command line. That is, if user wants to use plugin1 he types that name as a parameter in command line when running the app and I am supposed to load it on the fly.
Since I'm using plugin pattern I have an interface (since working in c++ it's an abstract class), that all of the plugins classes implement.
My dilemma is where to put the interface class? In order to have dlls built I will have to have a declaration of interface in every dll.
I want to avoid the need for changing the interface in all of dlls when there is a need for change in interface.
On the other hand if I declare interface class in main app my dlls wont be compiled and built?
Do you have a suggestion on how to extract the interface class from dlls and put it in the main app, so when I want to change it's code, wouldn't need to change it in a dozen of places (that is, in every dll).

Thanks in advance,

Cheers

+1  A: 

You will have to store the interface definition in a common location (separate .h file in say \inc subdirectory) and you will have to recompile all the libraries once you change the interface. There's no way around that in C++. If you need the ability to uniquely indentify interfaces you can use something like COM and change interface id each time you break the interface (again you will have to recompile the implementations, but with COM the client will not run into undefined behavior because of DLL hell).

sharptooth
+1  A: 

If by "interface" you are talking about the header file that describes your base-abstract class, I see no real issue.

You can share and use a file (here, a "header file") among several projects (a "project" is either your main application or one of your plugins). In your case, it actually makes perfect sense.

ereOn
A: 

Every DLL needs to have the same exported function that returns a pointer to your interface. Each DLL should be responsible for instantiating the 'interface' (Really subclass actually). So the main app will come along, call LoadLibrary on the DLL, and then using GetProcAddress, will call the exported function on the DLL. The exported function should then instantiate the concrete interface and return a pointer to it.

Question: "Where to put the interface" Answer: In your 'public' API folder.

C Johnson
A: 

Hi,

I once did this in C#, but maybe it can help you. I created an interface and abstract class in a separate project, which the main app and the plugins reference to. That way there is only one place for edits if necessary.

Main App.exe <-> PluginInterface.dll <-> APlugin.dll

Not sure how you would accomplish this in C++, I guess you could create a separate dll for the plugin interface and load it from your exe and your plugin dll's.

Hope that helps.

pika81