Single Responsibility Principle (SOLID)

The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.

You can check the history of the SRP from here

Imagine that you have a software program and you need to reuse a function, this function for example handling a Person email address validation you may do a copy and paste this function when you need to reuse it again, But it's not a good practice that's because this way will lead you to a redundant code and each time you need to add or remove something from this function you will need to modify all of these functions !!.

So we can solve it by understating our program functionality well and split these functions to classes and each class should do only one thing (a unique task).

For example we have a class that is responsible for handling the email validation and each time we have to validate an email address we will call this class that will handle the email validation, so we don't need to copy or paste this function to reuse it again.

Now, let’s add some email is validation logic to showcase the advantages of the SRP:

When an object doesn’t follow the SRP and it knows too much (has too many properties) or does too much (has too many methods) we say that the object is a God object. The preceding class Person is a God object because we have added a method named validateEmail that is not really related to the Person class behavior.

Deciding which attributes and methods should or should not be part of a class is a relatively subjective decision. If we spend some time analyzing our options we should be able to find a way to improve the design of our classes.

We can refactor the Person class by declaring an Email class, which is responsible for the e-mail validation and use it as an attribute in the Person class:

Now that we have an Email class we can remove the responsibility of validating the e-mails from the Person class and update its email attribute to use the type Email instead of string.

Making sure that a class has a single responsibility makes it easier to see what it does and how we can extend/improve it.

We can then simply use the Email class without explicitly perform any kind of validation:

So here we can import Email class in each time we need to validate an email address we don't have to write the validation function in each time we need to validate an email.

Also we can use this class Email when we need to create a Person like this

live demo

That's all, Please If you know anything that not mentioned here in this article please share it with me, stay tuned for the Liskov substitution principle (LSP).

Thank you