DEV Community

José Miguel Álvarez Vañó
José Miguel Álvarez Vañó

Posted on • Updated on • Originally published at jmalvarez.dev

Single Responsibility Principle in TypeScript

A class should have just one reason to change.

Every class in our code should be responsible for just a single part of the application. By following this principle we reduce the complexity of our code.

If a class is responsible of multiple parts of our app, it will have to be changed frequently. Therefore, changing one part of the class increases the risk of breaking other parts of itself. The solution is to divide it into multiple classes, each one with one responsibility.


In the following bad example we can see how the Student class has two responsibilities: managing the student data and the course data.

class Student {
  id: number;
  name: string;
  courseId: number;
  courseName: string;
  courseSubjects: string[];

  // constructor

  getCourseSubjects(): string {
    return this.courseSubjects.join(", ");
  }
}
Enter fullscreen mode Exit fullscreen mode

Following the Single Responsibility Principle we can improve this by moving the course data to its own class.

class Student {
  id: number;
  name: string;
  course: Course;

  // constructor
}

class Course {
  id: number;
  name: string;
  subjects: string[];

  // constructor

  getCourseSubjects(): string {
    return this.subjects.join(", ");
  }
}
Enter fullscreen mode Exit fullscreen mode

Top comments (4)

 
jmalvarez profile image
José Miguel Álvarez Vañó • Edited

I didn't mean that your objection is extreme, I'll quote a paragraph from the book "Dive into Design Patterns" by Alexander Sheets which better explains what I meant:

As with everything in life, using these principles mindlessly can cause more harm than good. The cost of applying these principles into a program’s architecture might be making it more complicated than it should be. I doubt that there’s a successful software product in which all of these principles are applied at the same time. Striving for these principles is good, but always try to be pragmatic and don’t take everything writ- ten here as dogma.

You are right that juniors could misunderstand this principle with my example. Thank you for your suggestion, I will update the post to avoid confusion.

Thread Thread
 
devworkssimone profile image
DevWorksSimone

I would instead keep it and add a brief explanation of why even that code break SRP. As a newbie it was helpfull to read through comment but not everyone may do it.

Collapse
 
jmalvarez profile image
José Miguel Álvarez Vañó

Thank you for your comment Luke. I will go through the content that you shared in the comment. Your point of view sounds very interesting. I rarely use classes in my daily work but it's the first time I see someone against them.

Yes, it's totally posible not to use classes. In this series of posts that I'm going to be doing my goal is to explain SOLID principles with examples in TypeScript for people who could be interested.

Collapse
 
jmalvarez profile image
José Miguel Álvarez Vañó

Thanks for the comment Tamas. You're totally right, in the example we are just applying SRP to the Student class. We could continue applying SRP to the Course class.

It's important to have in mind that principles should give you guidance. They should not be applied to the extreme without evaluating first if it makes sense.