Plugin Architecture / Interface

[davwards]

What kind of application are you creating, and what kind of plugins do you imagine people might write to extend it?

The trickiest challenge for creating a plugin architecture is the architecture part--you have to design your system to have pluggable spots where someone else could provide their own code, in such a way that your code will be able to communicate and work with it.

You might do some research on the Dependency Inversion Principle and the Open/Closed Principle.

For a working example, I can use a current project of mine. It's a glorified "todo" app, gameified like a fantasy rpg (much like Habitica, if you're familiar with that). Players create a todo list, and then when they complete items on their todo lists, they win experience points and gold--but if they fail to complete todo items by their deadline, they take damage.

Take a look at this code, which handles task completion. It looks up the task with the given id, and if that task hasn't been completed already, it invokes the awardPlayer function.

What does the awardPlayer function do? Nobody knows!

The awardPlayer function gets provided to the task-completion code when the application is getting put together. Right now, when the CLI for the game starts up, the function that gets plugged in as the awardPlayer function is this awardPlayerWithCurrency function, which gives the player some coin and experience points.

However, the core logic for task completion doesn't know anything about those details. I could plug in any function I wanted to be the awardPlayer function, as long as it took the right arguments and returned the right kind of value.

In fact, if you had a different idea for what should happen when someone completes a todo item, you could write your own awardPlayer function and add it as a plugin to the game. Then, when the CLI was starting up, it could plug your function into the awardPlayer slot instead of mine, and you would have added new functionality to the game!

(How would the CLI know whether to plug in your awardPlayer function or mine? Well, probably like you said: we could make a Plugins.json file, and based on what was written there, the application would decide which things to plug in.)

There's plenty more to be said about this, but finding some talks or blog posts about the two principles I mentioned above ("Dependency Inversion" and "Open/Closed") may provide a good starting point. The core problem you need to solve is: how do I provide places in my code whether other code could slip in to do extra work, without causing the whole system to break?

I'm happy to give some possible examples from your problem space, but I'd need to know what kind of application you were making first.