Shahmir Faisal
Shahmir Faisal

Shahmir Faisal

Single Responsibility Principle - SOLID Principles in Javascript

Single Responsibility Principle - SOLID Principles in Javascript

Learn about the Single Responsibility Principle to write better code.

Shahmir Faisal's photo
Shahmir Faisal
·Apr 23, 2022·

3 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Table of contents

  • What are the SOLID Design Principles?
  • Single Responsibility principle
  • Example

This is the first article in our series of articles covering the SOLID Design Principles.

What are the SOLID Design Principles?

SOLID is a set of object-oriented design principles allowing you to write understandable and maintainable code. It makes sure that changing one part of your code doesn't impact other parts. SOLID is an acronym for 5 key design principles:

  1. S - Single Responsibility principle
  2. O - Open-Closed principle
  3. L - Liskov Substitution principle
  4. I - Interface Segregation principle
  5. D - Dependency Inversion principle

In this series, we will cover all these 5 principles. We will cover the first one in this article.

Single Responsibility principle

The Single Responsibility Principle states that a class should have only one responsibility means that it should have only one reason to change or in other words, it should have only one job.
If your class has multiple responsibilities, it's better to split it into multiple classes to avoid the violation of single responsibility.

Example

Consider we're building an application to manage the students and their courses.

Naive Solution

We might have a class like this:

class Student {
  constructor(name) {
    this.name = name;
    this.courses = [];
  }

  enrollCourse(course) {
    this.courses.push(course);
    this.notify(course);
  }

  notify(course) {
    console.log(`${this.name}, you have successfully enrolled ${course}.`);
  }
}

const Shahmir = new Student("Shahmir");
Shahmir.enrollCourse("Physics");

// Output
// Shahmir, you have successfully enrolled Physics.

Here we have 2 properties, the name, and courses of the student. Then a function enrollCourse for adding courses and uses the notify function to notify the student about that course.
Now the solution looks good, isn't it? However, it's violating the single responsibility principle.

Why's it Violating the Single Responsibility?

If you carefully look at the above example, it has 2 responsibilities:

  1. Enrolling Courses
  2. Notifying Students about the new enrolled course

The class has 2 reasons to change:

  1. if we want to change how we're enrolling in the course
  2. if we want to change how we notify the user

Here are the problems with the notify function:

  1. What if we want to send an email or a push notification to notify the student instead of just printing the message in the console? We need to come back and make changes to the class.
  2. What if we have 10 different classes and we want the notify functionality in them? We need to write the function 10 times.
  3. And what if we want to change the function again? We need to make changes in 10 different places.

Better Solution

Why not just take that function out of the class? This will make the class use the single responsibility principle and we will be able to use that function wherever we want. And whenever we want to make changes, we will only change one part of the code without affecting the other parts.

function notify(message) {
  console.log(message);
  // we can also email or send a push notification
}

class Student {
  constructor(name) {
    this.name = name;
    this.courses = [];
  }

  enrollCourse(course) {
    this.courses.push(course);
    notify(`${this.name}, you have successfully enrolled ${course}.`);
  }
}

const Shahmir = new Student("Shahmir");
Shahmir.enrollCourse("Physics");

// Output
// Shahmir, you have successfully enrolled Physics.

Now the class has only one responsibility and that is to enroll the courses. The notify function is separate from the class.
So that's it. Will see you in the next article covering the open-closed principle.

Follow me on:
Twitter
LinkedIn
Github

 
Share this