What kind of problems have you encountered when building plugin interfaces for your application? And how did you resolve them?


I want to refactor an application so that various features can be moved into plugins, allowing them to be easily added and removed in future.

I hope this will be a neater system than scattering if (FeatureX_is_enabled) branches throughout the code. (I may be wrong!) I believe I will need to define interfaces for each part of the system into which a features may plug in.

I would like to benefit from your experience if you have already undertaken this kind of project. Perhaps you have endured mistaken designs, and can advise what not to do. Perhaps you can recommend patterns or architectures that can make such a system more manageable.


A few issues already spring to mind:

  • I will need to provide some power to plugins so that they can get their job done. If I pass too little control, new plugins may be too restricted to do what they need (e.g. some Google Chrome extension authors complain about the inability to modify the core interface). However if I pass too much control, irresponsible plugins will have the power to break the whole application (e.g. Mozilla Firefox extensions).
  • Some plugins may need to run in a different order on different events. I could register event handlers with a priority, e.g. 1-100, so that plugins can hook themselves into the appropriate order. Or I could just create post_ and pre_ events and hope nothing more finely grained is needed.
  • If two plugins depend on another plugin to be available first then the plugin architecture will need some kind of dependency (and naming) system.
  • Related, some plugins will need to know when other plugins are present, and perhaps even make calls into each other to handle edge cases.
  • There may be difficulties maintaining the state of the application if plugins are enabled and disabled at runtime. (Chrome seems to handle this well, but many applications require a restart.)
  • This kind of architecture will obfusticate the flow of execution (in exchange for keeping additional behaviour out of the core code). I will need to write neat interfaces so that unexpected behaviour is minimised.
  • Sometimes the monolothic if (FeatureX_is_enabled) approach might be a better way to handle the situation than breaking out to a plugin, but I don't know how to recognise such situations.

It is likely there are other concerns I have not considered, so I would love to hear what you have had to deal with!


Related question: How to turn on/off code modules?

Related library: Bemson's curious Flow library for Javascript seems to provide various features to help adding and removing features to/from a program at runtime, but I have trouble getting my head around it!

closed as too broad by gnat, user53019, user40980, amon, Euphoric Jan 25 '14 at 10:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I don't know the reason for the downvote, but I did try to find out where I could ask a subjective question, and that led me here. meta.stackexchange.com/questions/166086/… – joeytwiddle Jan 24 '14 at 6:00
  • Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. – gnat Jan 24 '14 at 8:30
  • 1
    Well, you actually asked six questions, didn't you? – Robert Harvey Jan 24 '14 at 20:55
  • 1
    Yes I have a number concerns, all of which fall under "How the hell do I write an application with features as plugins?" I would like to rewrite it, when I can work out how... Users with enough rep are invited to edit, or make suggestions. – joeytwiddle Jan 25 '14 at 0:52
  • This is a really interesting question, but far to broad and opinion-based. Thinking about various issues up front is good, but reality is usually more complex. Implement a plugin system, realize that it sucks (and why), build another one, release that as v1, then figure out how to include other features, then release that as v2 and use the new capabilities for marketing: “v2 plugins can now have dependencies! You can now register feature Foo handlers! We removed 80% of crashes when unloading plugins! – amon Jan 25 '14 at 9:19

I think the first thing to do is to ask who the plugin coder will be. Are you letting people outside your company create plugins or are plugins just a way to separate functionality? That determines how strict the interface must be. It is even possible to let diffrent plugins get different levels of functionality.

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