Single Responsibility Principle

If you are a passionate developer who’s interested in learning how to write high-quality software solutions, then you came into the right place, my friend.

One of the most common and effective software engineering principles is SOLID principles introduced by Robert C. Martin who is known as Uncle Bob. They are intended to make software designs more understandable, flexible, and maintainable.

SOLID is an acronym for 5 design principles:

1. Single responsibility.
2. Open-closed.
3. Liskov substitution.
4. Interface segregation.
5. Dependency inversion.

In this article, we’re going to talk about the first and easiest one which is the Single Responsibility principle.

Single responsibility principle says:

“A class should have only one reason to change”

But what does the phrase “only one reason” mean!

You know, I believe examples are the best teacher. Let’s read the following code snippet in order to understand.

class MusicPlayer{
   void playMusic(){
      System.out.println("Let the fun begins!");
   }
   void openPhoto(){
      System.out.println("Really! should I open the photo now?");
   }
}

As you can see we have a music player class that can play music and open photos.

Try to imagine that this class exists in some project at XYZ company who you work for. Khaled is a photographer at XYZ and uses the open photo function to open photos. Ali is another employee who is addicted to music and uses the play music function.

If Khaled decides to change the way photos are opened you are going to open MusicPlayer class and change the openPhoto function. Similarly, if Ali, a totally different employee, and maybe from a different department decided so. You will do the same but with the playMusic function.

We gave the class two different reasons to change and they are not related to each other. One for music and the other for photos. Besides, what is the relationship between MusicPlayer class and openPhoto function! I know you’ve thought openPhoto shouldn’t be there.

The class looks like a student who works at two totally different jobs. In software engineering, this is a bad practice. The more a class can do things the more it is susceptible to change, hence more bugs and problems.

Not only that, try to imagine if we decided to remove some lines of code from playMusic to find that openPhoto crashes. Different things in one place may affect each other. Bugs everywhere my friend, bugs everywhere!

So let’s separate the responsibilities and give a class one reason to change.

class MusicPlayer{
   void playMusic(){
      System.out.println("Let the fun begins!");
   }
}

class PhotoViewer{
   void openPhoto(){
      System.out.println("What about now should I open it?");
   }
}

Now if we decided to change the photo functionality at any time we won’t touch the music functionality and vice versa. Besides the functions are know logically related to the names of their classes.

In practice, it’s very hard to give the class only one reason to change with many functions exist, but what you can do is to keep its functions related as much as you can. This is generally known as cohesion in software engineering. Classes with high cohesion are an indication of good design.

You can apply a single responsibility principle also on functions. A function has to do one specific task no more no less.

Always ask yourself when you write a function what does it do? if you say it does something “and” something. And here means you’re doing it wrong.

This is the end of our journey for now.

Soon we’ll start another journey with the open-closed principle. Just wait for it!