Are You SOLID ? Part – S: Single Responsibility Principle

Hello all ? How is going with the lockdown and/or lockdown situtation ? Hardly the answer would be positive, I know though. 😉 But whatever it is , all the things happened are not in our control. So , what to do ? Many things, but one of them must be leveling up the skill since we are getting time enough to do so, not that ?

Okay, talked enough, let’s come to what I am writing this article for. All we love to code, but how many of us can maintain the quality of code always ? Maybe always or maybe not when it comes to the point when code/project delivery time is about to know the end line. Whatever it is, thing is the more we keep practicing to maintain the quality, the less we have to compromise it.

When it comes about quality, one question might arise, how can we maintain the quality, what does it actually mean. Yes, this is what this article for. Quality refers to maintain some principles when coding so that it would be easier to read, to refactor, to modify no matter how long you make a pause on working on it. Even after a long period of time you, or your other collaborator won’t find it hard to work with it.

Well, now let’s about SOLID. What is it ? It is actually the combination of 5 principles in object oriented programming, nowadays followed in general in almost all companies. These 5 principles are

S: Single-responsibility principle
A class or method or function should have only one responsibility. Your system might do thousands of tasks, processes, but a single class in there should to only ONE of them.

O: Open closed principle
Software entities should be open for extension, but closed for modification. You want to extend an existing class or method, you are most welcome to do that. BUT, if you want to modify it, NOPE, you are not allowed. -_-

L: Liskov substitution principle
Objects in an application should be replaceable with the instances of their subtypes without affecting the program’s functionality.

I: Interface segregation principle
It’s better to have many client-specific interfaces than one general purpose interface.

D: Dependency inversion principle
One should depend on abstractions, NOT concretions.

Single responsibility principle:

The title explains it enough. There might be many classes and methods in your program which are responsible to do different tasks , BUT each one of those class should be responsible to do one task.

Think of a User management module for example. This module is responsible to register users, let them login, authenticate them etc. We can think the structure of that program like the one below

class User_Module {

   function register() {
       //code to validate user
       //code to save use in database
    }

    function login() {
       //code to validate user
       //database query to check for the user
      //code to login
     }
}

Look at the code above, here a class is doing multiple tasks like validation, registration, logging in, databse query etc. These all are placed in one places which actually violated the S principle. Instead if we made this code separating the code into 3 classes where one would be responsible for registering user, another one is responsible for authenticating them, and another one for validation, it would be nicer.

//This class is responsible for registration
class Registration {
   function register($data) {
       //code to register
   }
}

//This class is responsible for validation
class Validation {
    function validation($request) {
        //code to validate 
    }
}

//This class is responsible for authentication
class Authenticate {
    function authenticate($request) {
        //code to authenticate
    }
}

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × three =