There are 5 SOLID principles, which we will explain below. In this post we will talk about the first one: Single-responsibility principle.

What are the SOLID principles?

SOLID principles are a set of basic principles of object-oriented programming and software design. When these principles are used, software with greater maintainability and, therefore, longer life is achieved. The 5 programming principles are: Single-responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. From the first letter of each is created the acronym that unites them: SOLID.

Single-responsibility principle

In this detailed exploration, we are going to talk about the first of the well-known SOLID principles: the principle of sole responsibility.

This principle was introduced by Robert C. Martin in the article “.“The Principles of the OOD”In it he stated that: “A class must have one, and only one reason, to change”.

If we can ensure that our classes only have one responsibility and, moreover, this responsibility is defined and concrete, the only reason why this class might need to change is if there is a change in business logic that affects it. 

How to detect that we are violating the principle of sole responsibility

In the journey towards the effective application of the single responsibility principle, it is essential to have the right tools to detect possible violations.

For this, we have several mechanisms that can help us to detect that we are not complying with this principle. The following are some of the symptoms that can help us to detect them. 

• Classes with too many lines of code.
• When a change is indicated to us we have to modify in many files.
• Failure to comply with the separation of layers in the software architecture.
• Failure to properly analyze responsibilities when developing software.
• When explaining what the class does, more than one responsibility is listed.
• Having more than one public method. 
• Difficulty in testing the class.

These indicators not only serve as alerts, but also point to specific areas that could benefit from greater attention and clarity. Mastery in identifying these symptoms is essential to maintaining a solid software design foundation based on SOLID principles.

Example:

Let's imagine that we have the following class: 

class User {
  builder(private readonly _name: string, private readonly _email: string) {}

  get name(): string {
    return this._name;
  } 

  get email(): string {
    return this._email;
  } 

  sendWelcomeEmail(): void {
    // Email sending logic 
  }
}

This class clearly has two responsibilities, obtaining user data management and sending user welcome email. 

If you would like to make a change in the email sending, the type of data collection would also be affected, since it is the same. 

To solve this, we should have 2 classes, one for obtaining user data and one for sending email:

class User {
  builder(private readonly _name: string, private readonly _email: string) {}

  get name(): string {
    return this._name;
  } 

  get email(): string {
    return this._email;
  } 
}

class Mailer {
  sendWelcomeEmail(user: User): void {
    // Email sending logic 
  }
}

In this way, any changes in the sending of emails or in the collection of user data only have an impact on the class in charge of it.

In our next blog posts, we will dive into the remaining four SOLID principles: Open-closed, Liskov substitution, Interface segregation and Dependency inversion. Each of these principles plays an essential role in creating robust and flexible software. We'll break down their meaning, explore practical examples, and provide tips on how to effectively apply them in your software development. Stay tuned for more content to come.