That makes sense...I was going for the one plugin manager approach, but maybe I should rethink that [wink]
Thanks dmatter!
Object Factory question
You have two basic approaches. First is having one and only master plug-in definition:All plugins extend the above. Every function defines some functionality, and functionality as a whole. Plugin author extends the interface and implements what's necessary.
Due to default implementation, they only override what they actually support, and adjust has_capability accordingly.
Another approach is interface per capability:
Authors extend the plugin the want, and implement the virtual method(s).
Another option would be using DLLs.
Next, comes the instantiation of the implementations. A plugin is a basically a tuple of (functionality, implementation). What you need to decide now is the actual relation. For each functionality, can there be (0 or 1), exactly 1 or more than 1 plug-in.
Once you decide on that, you can write your factory. For first two cases, the abstract factory will work.
Read implementation descriptors from some file, or search a directory to populate the factory. Then you get the basic interface:
Additional information can be tucked into various parts of plugin implementation (names, parameters, etc..).
struct PlugIn { virtual void load() = 0; virtual void unload() = 0; virtual error_t foo() { return E_NOT_SUPPORTED; } virtual error_t bar(const char *name) { return E_NOT_SUPPORTED; } virtual error_t baz(X * x) { return E_NOT_SUPPORTED; } bool has_capability(Capability c) { return false; }};Due to default implementation, they only override what they actually support, and adjust has_capability accordingly.
Another approach is interface per capability:
struct Plugin { virtual void load() = 0; virtual void unload() = 0;};struct Bar : public PlugIn { virtual do_bar() = 0;};Authors extend the plugin the want, and implement the virtual method(s).
Another option would be using DLLs.
Next, comes the instantiation of the implementations. A plugin is a basically a tuple of (functionality, implementation). What you need to decide now is the actual relation. For each functionality, can there be (0 or 1), exactly 1 or more than 1 plug-in.
Once you decide on that, you can write your factory. For first two cases, the abstract factory will work.
Read implementation descriptors from some file, or search a directory to populate the factory. Then you get the basic interface:
// first case, with uniform interfacePlugIn * createInstance(const std::string &functionality);...PlugIn * bar_plugin = createInstance("bar");PlugIn * foo_plugin = createInstance("foo");// second case, typical templated solutiontemplate < class Functionality >class PlugInFactory { PlugIn * createInstance();};...PlugInFactory<Foo> fooFactory("/plugins/foo.cfg");PlugInFactory<Bar> barFactory("/plugins/bar.cfg");PlugInFactory<Baz> bazFactory("/plugins/baz.cfg");...Bar * barPlugin = barFactory.createInstance();Additional information can be tucked into various parts of plugin implementation (names, parameters, etc..).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
