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?

  • Patterns like Observer, Mediator,Command ad Chain of Responsibility come to mind
    – Mchl
    Jul 14, 2011 at 11:00
  • 3
    @Mchl: Please post your answer as an answer, not as a comment.
    – S.Lott
    Jul 14, 2011 at 11:05
  • You should take a look at Mef and the MSDN info
    – Luc Bos
    Jul 14, 2011 at 11:21
  • I feel it to be not detailed enough for that
    – Mchl
    Jul 14, 2011 at 11:50
  • @Mchl: "not detailed enough"? Then why comment at all? It's clearly an answer. Please post answers as answers.
    – S.Lott
    Jul 14, 2011 at 14:07

3 Answers 3


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

  • 1
    +1 It does not directly answer the question, but these are important issues to have in mind Jul 14, 2011 at 14:37
  • I believe these issues are covered before anyone starts developing the actual extensibility mechanism
    – Gus
    Jul 14, 2011 at 15:53

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:

  • You define a contract (normally an interface) between the host and the extension
  • You need a discovery mechanism that goes out and looks for installed extensions
  • You need to be able to dynamically load the extensions and make the host aware of them

In practice it shares a lot with Dependency Injection and the Strategy Pattern.

  • +1 MEF and System.AddIn are both good things to look at. Even if you don't end up using them they both show good concepts. Jul 14, 2011 at 12:40
  • @jkohlhepp - I agree, and I would also suggest a deep dive into the SharpDevelop architecture because there's a lot written about it, it's open source (so is MEF, btw), and it's well designed. Jul 14, 2011 at 12:46

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.