We were talking a lot about decoupling software using Dependency Injection and Inversion of Control.

When we reach a good decoupling level, we can start to build software as a plugin.

In this post, I am going to talk about software as a plugin and some of his features.

Plugins Series

• Part 1: Plugins: Software as a set of interchangeable parts (You are here)
• Part 2: Interfaces and Replacement: The Liskov Substitution Principle

What is Software as a Plugin?

We splitted the software in Main and Abstraction:

Now, let’s transform this concept as software as a plugin:

We now see how an application is made of different plugins, those are managed by Main and distributed through the whole application.

A plugin is a piece of software that does pretty well a specific work, like defining Restful services, accessing a database, and so on.

The more interesting part of a plugin is that can be replaced by other plugin, that does the same job, but, in a different way, and your application won’t notice it.

NOTE: Your Abstraction is another plugin in your application, and it usually needs other plugins to work.

REMEMBER: As your Abstraction needs other plugins, you must apply what we saw in previous posts about Dependency Injection and Inversion of Control.

Defining Plugins

Let’s use the following example we saw on a previous post:

Now, let’s define which are plugins there:

We have here three plugins:

• Abstraction plugin: This is our business rules, we usually won’t change this plugin for other, because is our core. However, this plugin usually uses other plugins, like in this case, the MySQL plugin.
• MySQL plugin: Defines the database access to a MySQL database. This plugin implements the Repository contract.
• Main plugin: This is our start up, in this case Spring, however, it can be JEE or Activities in Android apps.

Abstraction Plugin is the Most Important One

Abstraction plugin has our business logic, it means, we must build it pretty well to not depend on things that are not important (Dependency Injection and Inversion of Control).

As our Abstraction plugin needs other plugins to work, we should define how our Abstraction will interact with an specific plugin.

For instance, we create a Repository plugin specification that defines what is needed for our Abstraction in relation with data access.

If we move this interface to be defined into a specific plugin, we lost the capacity of replacement, we are coupling our Abstraction plugin against a specific data access plugin.

NOTE: A plugin specification is not only an interface, you might need Value Objects, DTOs, Utilities and so on.

Is It Easy to Create Plugins?

Short answer, not, it is not.

For example, you create a new plugin, like MongoDB plugin, implement the right interfaces from your Repository plugin definition, and your project will compile well. However, when you use your new plugin, your application could fail in runtime…. why?

Well, you might have broken the Liskov substitution principle.

Final Thought

Software as a plugin is a powerful concept, however, it is pretty difficult achieve, moreover, when you need to trade off your decisions in a normal project.

In a following post, I am going to talk about the Liskov substitution principle and how failing applying that could limit our decoupled software.

If you liked this post and are interested in hearing more about my journey as a Software Engineer, you can follow me on Twitter and travel together.