Object Oriented Design Principle: The Single Responsibility Principle (SRP)

SRP principle

Look at the guy above. He’s an employee of a company. While doing his work, he diverts his attention to other things — doing side projects, answering personal phone calls, browsing social media sites, etc. After no work being done, his boss fired him. In short, NOT focusing on one responsibility at a time kills you!

It’s the same in object oriented programming. Classes that have many responsibilities is difficult to change, debug, and maintain. Having single responsibility implies simplicity. The simpler your code is, the easier to maintain. On the other hand, having multiple responsibilities to classes indicates complexity. Complexity makes the system hard or cannot be maintain. Therefore, complexity kills your project!

There’s a principle to the rescue,

It’s the Single Responsibility Principle (SRP).

The SRP principle states that,

Every object in your system should have a single responsibility, and all the object’s services should be focused carrying out single responsibility.

Now, let’s take an example that violates this principle.

Vehicle.java


public class Vehicle {
    public void start() {
    }
    public void stop() {
    }
    public void changeTires( Tire[] tires ) {
    }
    public void drive() {
    }
    public void checkOil() {
    }
}

If you understood well the definition of SRP, you can spot the methods that made the Vehicle class violates SRP. 

Take a minute to think before reading the answers below!

If you can’t spot them, here’s the technique:

The                                                            itself.

  1. In the first underline, place your class name in there.
  2. For the second underline, place each method name.

Then analyze the sentence, if it makes sense, it doesn’t violate SRP.

Let’s analyze the first two methods.

  • The Vehicle starts itself.
  • The Vehicle stops itself.

It makes sense, the Vehicle is responsible for starting and stopping the engine.

  • The Vehicle changeTires itself.
  • The Vehicle checks oil itself.

No! You need a mechanic to change the vehicle tires and to check the vehicle’s oil. How can a vehicle change its tires and checks oil itself? Oh! It’s possible, only when the vehicle is very high-tech and robotic! But this vehicle I’m making is just an ordinary vehicle!

  • The Vehicle drives itself.

Again, it doesn’t make sense. You’ll need a driver to drive a vehicle!

Let’s solve this!

Much simplier Vehicle class.

public class Vehicle {
    public void start() {
    }
    public void stop() {
    }
}

Changing the tires and checking oil is really the responsibility of a mechanic.

public class Mechanic {
    public void changeTires( Vehicle vehicle, Tire[] tires ) {
    }
    public void checkOil() {
    }
}

And then the driver,

public class Driver {
    public void drive( Vehicle vehicle ) {
    }
}

The code above might violate other design principles like “Programming for Interface Not Implementation”. But for this SRP principle, I just show you how to separate responsibilities.

Imagine you have many classes in your project, and each class overlaps responsibilities, it’s so difficult to maintain whenever the requirements of the project would change. Again, the simpler your code is, the easier to maintain.

SRP doesn’t apply only to classes but also other modules in your code like methods. So you make sure your methods has only single responsibility.

By the way this principle is also similar to cohesion. If you followed SRP correctly, then your code is considered highly cohesive.

For more design principles, click here.

I’m not an expert on this topic. If you disagree with me just let me know, I would love to hear it from you.

If you have learned something on this blog post, don’t forget to follow my blog to receive email notifications for new my posts. Also, share it to your friends to any social media you like.

Happy Learning!

Advertisements

8 thoughts on “Object Oriented Design Principle: The Single Responsibility Principle (SRP)

  1. Nice post. I have never considered the “the __ __ itself” approach. That’s a great way of putting it. Thank you for writing this.

    Liked by 1 person

  2. Excellent example of this very important principle.
    I’m officially adopting the “The ___ ___ itself”
    guideline.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s