Applying Single-Responsibility Principle To Libraries

The Single-Responsibility Principle or SRP of SOLID is one of those wonderful little principles that can apply to so much, from your objects to methods to libraries (blog posts, emails, so many other things in your life). I want to focus on libraries for the moment. As I refer to libraries, I mean any bundle of code that is compiled and deployed as a unit. This could be .NET Assemblies, Java JAR Files, whatever your platform uses.

SRP describes the goal of keeping your objects focused on one thing and one thing only. This keeps undesired dependencies and complexity from creeping in. Instead, of munging all the logic into one “God Object” you break the logic into smallest possible objects, making changes to a specific object much easier because you don’t have to worry about breaking some other tangled up responsibility. But let’s change a little terminology, instead of “objects” let’s swap in the word “libraries”. This gives us the goal of keeping our libraries focused on one responsibility and instead of a “God Library” we want to have discrete, focused libraries that do one thing.

Why would this be a good thing? Consider an application that has the entire business framework, business logic, data access and UI logic all contained in one assembly. You have three applications that utilize the library, one to handle web services, one to handle file transformations and another is your companies flagship web application. Now, this is convenient if you always deploy all three applications simultaneously. You only have one library to worry about, just compile and deploy everything. But let’s say you want to change something in the file transformation logic but don’t want to have to redeploy the website? Now you have to try to figure out how to deploy a new version of the master library without impacting the website. Typically, you’ll end up with multiple versions of the same library and a version headache. How can you avoid this? By breaking up the libraries.

Instead of one master library separate your application structure up by responsibility. Our example would probably become three new core libraries, one for the framework, another for data access and business logic and then we’d create libraries for our file transformation logic and web application. This way, when we make a change to the web application we don’t *have* to redeploy the file transformation service and vice-versa.

I’ve used this approach in dealing with my current employer. We have two .NET assemblies that pretty much hold the entirety of the core application and all of it’s sub-processes. These assemblies are stored in the GAC so pretty much, if you want to redeploy the file transformation service you have to also redeploy three other application and the website. By refactoring the file transformation logic into a separate assembly I was able to work freely on the file transformations without having to concern myself with accidentally breaking our primary business systems.