What are some different ways of implementing a plugin system?

Question

I'm not looking so much for language-specific answers, just general models for implementing a plugin system (if you want to know, I'm using Python). I have my own idea (register callbacks, and that's about it), but I know others exist. What's normally used, and what else is reasonable?

What do you mean by a plugin system? Does Dependency Injection and IOC containers sounds like a good solution?

I mean, uh, well, a way to insert functionality into the base program without altering it. I didn't intend to define it when I set out. Dependency Injection doesn't look particularly suitable for what I'm doing, but I don't know much about them.

Answer 1

What do you mean by a pluggin system? Does Dependancy Injection and IOC containers sounds like a good sollution?

Answer 2

In Python you can use the entry-point system provided by setuptools and pkg_resources. Each entry point should be a function that returns information about the plugin -- name, author, setup and teardown functions, etc.

Answer 3

A simple plugin architecture can define a plugin interface with all the methods the plugin ought to implement. The plugin handles event from the application, and can use the application's standard code, model objects, etc. to get things done. Basically the same as an ASP.NET Form does, except that you're overriding rather than implementing.

Nobody taught me this part, and I'm no expert, but I feel: In general a plugin will be less stable than its application, so the application should always be in control and only give the plugin periodic opportunities to act. If a plugin can register an Observer, then calls to the delegate should be tried/caught.

Answer 4

There is a very good episode of Software Engineering Radio, which you may be interested in.

For future reference, I have reproduced here the "Rules for Enablers" (alternative link) given in the excellent Contributing to Eclipse by Erich Gamma, Kent Beck.

• Invitation Rule - Whenever possible, let others contribute to your contributions.
• Lazy Loading Rule - Contributions are only loaded when they are needed.
• Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
• Fair Play Rule - All clients play by the same rules, even me.
• Explicit Extension Rule - Declare explicitly where a platform can be extended.
• Diversity Rule - Extension points accept multiple extensions.
• Good Fences Rule - When passing control outside your code, protect yourself.
• Explicit API Rule - separate the API from internals.
• Stability Rule - Once you invite someone to contribute, don?t change the rules.
• Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.

Answer 5

How about abstract factory? Your base program defines how the abstract concepts interact with each other, but the caller has to provide the implementation.