Question

I have been working on this plugin system. I thought I passed design and started implementing. Now I wonder if I should revisit my design. my problem is the following:

Currently in my design I have:

1. An interface class FileNameLoader for loading the names of all the shared libraries my application needs to load. i.e. Load all files in a directory, Load all files specified in a XML file, Load all files user inputs, etc.

2. An Interface class LibLoader that actually loads the shared object. This class is only responsible for loading a shared object once its file name has been given. There are various ways one may need to load a shared lib. i.e. Use RTLD_NOW/RTLD_LAZY…., check if lib has been already loaded, etc.

3. An ABC Plugin which loads the functions I need from a handle to a library once that handle is supplied. There are so many ways this could change.

4. An interface class PluginFactory which creates Plugins.

5. An ABC PluginLoader which is the mother class which manages everything.

Now, my problem is I feel that FileNameLoader and LibLoader can go inside Plugin. But this would mean that if someone wanted to just change RTLD_NOW to RTLD_LAZY he would have to change Plugin class. On the other hand, I feel that there are too many classes here. Please give some input. I can post the interface code if necessary. Thanks in advance.

EDIT:

After giving this some thought, I have come to the conclusion that more interfaces is better (In my scenario at least). Suppose there are x implementations of FileNameLoader, y implementations of LibLoader, z implementations of Plugin. If I keep these classes separate, I have to write x + y + z implementation classes. Then I can combine them to get any functionality possible. On the other hand, if all these interfces were in Plugin class, I’d have to write x*y*z implementation classes to get all the possible functionalities which is larger than x + y + z given that there are at least 2 implementations for an interface. This is just one side of it. The other advantage is, the purpose of the interfaces are more clearer when there are more interfaces. At least that is what I think.

Answer 1

My c++ projects generally consists of objects that implement one or more interfaces.

I have found that this approach has the following effects:

• Use of interfaces enforces your design.
• (my opinion only) ensures a better program design.
• Related functionality is grouped into interfaces.
• The compiler will let you know if your implementation of the interface is incomplete or incorrect (good for changes to interfaces).
• You can pass interface pointers around instead of entire objects.

Passing around interface pointers has the benefit that you’re exposing only the functionality required to other objects.

COM employs the use of interfaces heavily, as its modular design is useful for IPC (inter process communication), promotes code reuse and enable backwards compatiblity.

Microsoft use COM extensively and base their OS and most important APIs (DirectX, DirectShow, etc.) on COM, for these reasons, and although it’s hardly the most accessible technology, COM’s not going away any time soon.

Will these aid your own program(s)? Up to you. If you’re going to turn a lot of your code into COM objects, it’s definitely the right approach.

The other good stuff you get with interfaces that I’ve mentioned – make your own judgement as to how useful they’ll be to you. Personally, I find interfaces indispensable.