SOLID - Single Responsibility

In this blog, I want to talk about the first principle of SOLID, which is Single Responsibility.

First of all, WHAT IS SOLID?

 

It is the set of five principles of object-oriented programming and code design, created by Uncle Bob (Robert C. Martin).

 

That is, it is a set of good practices that when used correctly guarantee low coupling, reuse of code, separation of responsibilities among others.

 

In my opinion, it is one of the most important principles in the development of object-oriented systems.

This principle is very common, I'm sure you've used it and still use it.

 

Before beginning to show the most varied examples it is important to understand the concept behind this principle, it is nothing too complex, but it is fundamental, that is, every object must have a SINGLE responsibility, nothing more!

 

I like to always think of real-world examples before I think of code examples. So I'd like to put some examples that make sense to me.

 

The only responsibility of a knife is to cut, nothing more. I know it can be used for various functions, but it was not made for the other functions but for the main function that is cut.

 

What is the responsibility of an electrical outlet? Through an interface, it provides electricity to the plugged equipment.

 

A lawnmower has the responsibility of mowing the lawn and nothing more.

 

Why use this principle? What will it help me with on a daily basis?  It will help me to reuse code, with low coupling, easy to perform unit tests, and a better understanding of the code for future implementations or patches.

 

It is important before developing any class and/or method to ask yourself, "Is this the main responsibility of that object?" If the answer is: "Maybe," most likely the principle is not being followed.

 

Let's imagine the following scenario,

 

The client requested the following functionality in the system.

 

Make the inclusion of a product and soon after the inclusion return all the products registered.

 

If we do not use this principle the code would look like this, 

public IEnumerable<Product> InsertProduct(Product product)
        {
            _dbContext.Products.Add(product);
            Save();
            return _dbContext.Products.ToList();
        }

Note that this method has two responsibilities, to enter the product data and to select the products already registered, thus the principle of single responsibility is not being applied.

 

Using the principle of single responsibility, let's see how this functionality should be implemented,

public void InsertProduct(Product product)
      {
          _dbContext.Products.Add(product);
          Save();
      }

This method has only the responsibility of entering the data in the database,

public IEnumerable<Product> GetProducts()
        {
            return _dbContext.Products.ToList();
        }

The only responsibility of this method is to list the products already registered.

 

Note that with the creation of these two methods we guarantee the principle of single responsibility and the reuse of code since the methods can be used separately.

 

Conclusion

 

This principle is very simple and very ,uch used, however, before starting coding it is interesting to breathe, to have a coffee and to think if what we are going to code is the responsibility of that method and/or class.