If you have an application of some sort and you want your users to be able to write plugins for it, how should the application be designed?
What do you have to take into account, what design patterns are for this etc?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityIf you have an application of some sort and you want your users to be able to write plugins for it, how should the application be designed?
What do you have to take into account, what design patterns are for this etc?
It kinda depends on your platform but some general things to keep in mind
Versioning What happens if you update your application, does all old plugins become obsolete (the firefox problem)
Isolation Can plugins do whatever they want? Do you always trust them? Or do you need to run them in some sort of sandbox and request permissions.
Updates How do you handle plugin-updates?
Security How do you ensure the author of a plugin, prevent spoofing or the user being tricked into installing malicious code. Usually solved by some sort of code-signing
Serialization Often when you use isolation of some sort you need to serialize information between different threads or processes. How do you do that most efficiently?
Extensibility What aspects do you need to extend? How do you maximize the potential of plugins without the API becoming unwieldy.
If you're targeting third-party developers for plugins I'd say the most important thing (from my experience) is to see the plugin api and classes as completely different from the rest of the application, and make it as easy to develop for as possible. It's very easy for architecture from the main app to "bleed over" into the plugins so that plugin authors have to learn much more than they have to. Make it easy for them, think on what kind of interface and experience you'd want as a plugin author.
Another good mindset is not to think like "The plugin will do all these things (in code) but rather, "the plugin needs to provide this information". That way the application can consume the necessary information and do the actual processing which will simplify the plugin.
Also in general, whenever you can go a descriptive approach (metadata, like xml) rather than code you have a big advantage since metadata is easier to transport, version, deploy, secure and can more easily be configured by third-parties
I wrote this Code Project article about using MEF for extensibility in .NET. It's a good introduction.
There are other extensibility frameworks for .NET, such as SharpDevelop's Add-in Architecture, Mono.Addins and System.AddIn.
For Java, there is the Eclipse Plug-in Architecture.
The general pattern is this:
In practice it shares a lot with Dependency Injection and the Strategy Pattern.
You just need to provide an interface for the plugins.
It should contain at least an Activate-Methode (an entry point), but you'll want things like Initialize etc. as well.
And there should be the possibility to communicate with the host application in a registry-like manner, for example to register menu items. So registries for things that are changeable/extendable for plugins should be provided.
Also, there should be some accessible storage for the host application's data and objects, so plugins can call its routines. This can easily be done by using a DI-Container like Unity and letting the plugins access it, so they can resolve the services they need.
An Event-Aggregator is probably a good idea also, so the plugins can throw events and react to events from other plugins and the host application in a decoupled manner. You definitely want one!