Sign in to follow this  

good practices for developing an API?

This topic is 3806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am developing a framework that incoporates a dynamic lib based external plugin system. I am running into some basic problem and am looking for some input on the problem I have an any general practices for developing APIs. The design is a basic framework that allows for the runtime creation of dynamic objects. The dynamic objects are defined by external dlls so that functionality can be specified outside of the framework. As such I have a framework engine with a a Module Manger. The Module Manger will, at run time, load any requested dlls. The Modules interface defines basic functions needed by external modules to register itself with the framework. So to create a external module, I would include the header for my Module and define a class that inherits from my Module base type. This all works fine, but... As part of the Module, I use boost libraies for threading and object pooling. Because Module's header files look for boost headers, I not only need to have my API related headers present, but also all the boost header files! Example: //Module.h #include <boost/whatever.h> Module { boost::auto_ptr myPtr; } //EOF //my custom plugin #include "Module.h" MyModule : public Module { ... } When I try to build MyModule by itself, it wants all the headers for boost. Is there a way around this? How do other APIs handle relying on external libraries? Also if anyone has any links to good articles on developing plugin architectures and APIs please share. Thank you, Aaron

Share this post


Link to post
Share on other sites
You might want to look at the PIMPL idiom. It works by hiding the implementation details of your classes behind a thin wrapper class. It might or might not work for you.

It works by having the class that does the actual work (Module in your case) wrapped in another class that has an identical interface and a pointer to the 'hidden' class.


// Module.h
#include <boost/whatever.h>

class Module
{
boost::auto_ptr myPtr;

public:
void SomeMethod(void);
};


// ModulePIMPL.h

class Module;

class ModulePIMPL
{
Module* module_;

public:
void SomeMethod(void);
};


// ModulePIMPL.cpp
void ModulePIMPL::SomeMethod(void)
{
module_->SomeMethod();
}


This is a way to hide boost (or any other libraries) from the API users. There might be a problem though, since your example shows users of the API deriving from the Module class. This derivation should now be done from the ModulePIMPL class. So your API should work through (virtual) functions only, no access to data members through derivation can be allowed.

Share this post


Link to post
Share on other sites
Another possibility is going for (abstract) interfaces. Only provide the method names and parameters (they need to be free of boost then).

In any way try to avoid having code in the basic module class, this will build up problems later down the road. Imagine you change some functionality of the basic module class, but the plugin doesn't know that.

Share this post


Link to post
Share on other sites

This topic is 3806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this