Plugins, why should I care?

In my last post, Watch your Composition Root, while exploring how I keep my bootstrapping code nice and tidy, I point out that the approach workes very well when implementing the plugin pattern. Rob Earlam provided me with some feedback that I explain the how of plugins but neglected the why, so let's add that functionality now.

"You mention the plugin pattern very briefly, but I think you should expand on that, as the isolation that pattern gives you is the main reason for implementing this. This is something you'd do when following the Principals of package design from Uncle Bob, (which Helix is based off). Defo worth expanding on that here I think, as you've done a great job of the how, but kind of left out the why?" - Drunk Rob

So why would you even bother with this pattern? Rob answers it quite succinctly: "isolation". Although this is very important, it is just a subset of the real star of the show, independence. If you are "careful" plugins can provide this by default, allowing different developers to work on different areas of an application with minimal to no interference; it allows this by reducing the chance that changes to plugin code will cause unrelated defects elsewhere as the code is isolated, your plugin depends on the application and not the other way around. This also allows for independent deployability, where a change to one plugin does not necessarily require a recompile and redeploy to other parts of a system.

If we take a step back from a "Just the code" mindset and consider all the supporting assets that makeup features in an application, images, configuration, executables, etc; you can conclude that all of these things could be combined into one deployable package. This is something that I have seen time and time again and am quite a fan of. Drupal is a great example of this idea in action, if you want to add functionality you create a module, this is a collection of all the logic and assets to bring your feature to life, in fact, Drula Core is made up of a large collection of modules that provides the out of the box functionality.

When building large systems it's not uncommon for things to break in weird and wonderful ways, as this (for me anyhow) is just a part of programming, but it is not acceptable to be introducing defects in other, unrelated, parts of the system. Using plugins is a great technique that can help you avoid creating these unacceptable defects. As I slowly move more and more to this way of developing I hope to share my experiences. However, in the meantime, I need to do a lot more internal rationalising when it comes to the "Principals of Package Design" to allow me to create meaningful/helpful blog articles on the subject.