SOLID principles, in layman's terms: Single Responsibility

Raison d'être: I set out to write about the SOLID software development principles. Specifically, my aim was/is to make these things more understandable to other developers who, much in the way as yours truly, found it troublesome to have to decipher lengthy, complex articles and books on the matter. These principles are for everyone to learn and use, but I found that they were hard to fully grasp; quite possibly because I come from a non-English speaking background. So with this series of articles I'm setting out to try and de-mystify the principles, with only the best intentions in mind. The principles apply to many layers of software development. In my articles, I specifially aim to describe them as they relate to programming. I hope it'll be of use to you. Thank you for stopping by.

This will be a 5 article-series about SOLID. SOLID is all the rage; at least as far as the job-adds I'm reading are concerned; "you are expected to honor the SOLID principles" etc. So what exactly is SOLID about? Plain and simple, it's a set of guide-lines in developing object-oriented systems. They are a group of concepts that have proven themselves valuable for a great many people coding a great many pieces of software. A tale told by your elders in software engineering, if you will, that you will want to pay heed to so you can boast on your CV that you're into the SOLID principles - and you'll be a better developer for knowing them, I promise you that. Heck, you're a better developer for simply _wanting_ to know them!

[S]OLID - The Single Responsibility principle

The Single Responsibility is the first in the set of principles that make out the SOLID acronym. It states that a class should have only one single reason to change. And one reason only.

And why is this a good thing? Because the clutter from having a class do too much stuff is long-term damaging to whatever you're trying to design.

That distinction - "a single reason to change" - is important. The principle is not "a single thing to do"; a class may certainly perform one or more related tasks within the same scope of the class' responsibility. For example, a class which performs logging to a text-file and a database would not be considered breaking the single responsibility principle. If you were to add functionality to log to, say, a central systems management tool, that's not breaking the principle: that class is still only having one reason to change, and you have merely exercised that reason. But if you were to introduce functionality to send a notification on, say, the log-disc being close to full - that's breaking the principle: new stuff to do, unrelated to the primary responsibility.

Below is listed the primary risks involved in not following the principle, as well as the benefits of, well, following it. But first let's go about how to fulfill the principle. It's very simple, really: Go through your classes and look for those that perform two or more different actions. For example: do you have a class that renders an object AND saves it to disk? Not good - the class is clearly having more than 'one reason to change' - it might be a change in the rendering, or a change in the persistence to disc-functionality. Take the below example:

public class Logger
{
    public Logger()
    {
    }

    public void WriteLog(string message)
    {
        // do something to write the message to disk log
    }

    public void GenerateLoggingStatistics()
    {
            // do something to retrieve some stats
    }
}

... which finds us with a Logging-class that writes to a log-file and is capable of generating some logging statistics as well. I'm not familiar with any form of tooling which may aide in this kind of 'single-context search', unfortunately. All I can offer is this, that you'll likely be looking to keeping your classes short. Big classes - my personal, general rule of thumb is 200 lines - marks a danger-sign that the class has too much on its plate. Further to that point, It's not necessarily a danger-sign that you have a multitude of small classes as opposed to a few heavy ones - likely quite the opposite. Keep'em short and lean. In regards to how to facility future changes without breaking the principle, look to hide implementation by interfacing, and there's also the magnificent strategy-pattern to be utilized.

That's it - that's the single responsibility principle, the first of the five. Not so terribly difficult, but then again that's the beauty of the principles, that they're easy to learn but difficult to master. I best saw the adverse of applying the principle described as a 'swiss army-knife class'; if you keep that image in your mind as you traverse your own, you're bound to avoid ending up with exactly those kind of 'do-all' classes. And as an extra positive, classes that are lean and mean are per definition easier to test, easier to read, easier to maintain. And that's what the Single Responsibility principle is all about.

Hope this helps you in your further career. And good luck with it, too!

Buy me a coffee