Part of the SOLID principles of Object Oriented Design, the Single Responsibility rule – or more correctly called guideline – is there as a reminder to help guide all our coding endeavors, from the first line in the first method to all the subsequent modules and classes that will work effortlessly towards your end goal.
In Object Oriented Programing or Object Oriented Design the SOLID principles are an acronym for a series of design guidelines:
S – Single Responsibility
O – Open-Closed
D – Dependency Inversion
Back to the Single Responsibility Principle. First, in a concise definition, it states that a Class should have one and only one reason to change, thus meaning that it should have only one job, or responsibility.
In layman terms, a class should only do 1 thing and do it well. But why?
To understand why, first we should see why not, and for that we take a quick look at the alternative. A class that has more than one responsibility is difficult to reuse. And it is difficult to reuse because you cannot call upon the class to fulfill 1 responsibility without the other class responsibility to come-a-knocking like clippy – “Hello, it seems that you are trying to code, would you also like to exercise your debugging skills?”
Now you know the reason why, but not why the problem arises in the first place. Well first off you need to understand that you are dealing with a machine. It lacks judgement or a consciousness (as far as we know) and as such it can only do what you tell it to do.
It cannot look inside a Class and decide all on it’s own what bit is good and when it’s good exactly. As far as it is concerned, all of it is good, all of the time – because you told it so, and it trusts you. For it, having two responsibilities in one class basically means that it’s just “one package” indivisible and unchangeable as far as it knows or cares. They are two responsibilities for you, because you are conscious and have judgment and can discern the difference between the two.
So what should you do? Well you should start by not breaking your machine’s trust in you and writing reusable code. Applications that embrace simple classes , with small dedicated methods and adhere to the Single Responsibility Principle are easy to change, simple to reuse and straightforward with their intentions.
Think of your code like bricklaying. Each brick satisfies one single purpose, to fit in seamlessly with the other bricks.
Now I want to share with you a small but very powerful secret. The Single Responsibility Principle is not limited to classes only. The Single Responsibility Principle is a programming principle in general. It extends to all your code, and that includes your methods.
In Object Oriented Programming, if your classes are your arteries then your methods are the life-blood of your application. Suffice to say they are very important and as such you should treat them with the same love and care. So when you define a method, think to yourself – “is this the one and only job of this method”. If the answer is no, then you should consider refactoring your code. But more about refactoring and the one thing you need to be able to refactor code will be discussed at a later time.