Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Patterns like Observer, Mediator,Command ad Chain of Responsibility come to mind –  Mchl Jul 14 '11 at 11:00
2  
@Mchl: Please post your answer as an answer, not as a comment. –  S.Lott Jul 14 '11 at 11:05
    
You should take a look at Mef and the MSDN info –  Luc Bos Jul 14 '11 at 11:21
    
I feel it to be not detailed enough for that –  Mchl Jul 14 '11 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 '11 at 14:07
add comment

3 Answers

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

share|improve this answer
1  
+1 It does not directly answer the question, but these are important issues to have in mind –  Adrian Jul 14 '11 at 14:37
    
I believe these issues are covered before anyone starts developing the actual extensibility mechanism –  Gus Jul 14 '11 at 15:53
add comment

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.

share|improve this answer
    
+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. –  RationalGeek Jul 14 '11 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. –  Scott Whitlock Jul 14 '11 at 12:46
add comment

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!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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