\n\nRepost of https://dev.to/huzaifa99/why-you-should-be-following-the-single-responsibility-principle-1h2a
\n
For those of you already familiar with the SOLID Design Principles, this won’t be much of a new thing. For newbies however
\n\n\nSOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.
\n
They are more like best practices rather than a rule.
\nThe S in SOLID.
\nIt says
\n\n\nA class should have one, and only one reason to change.
\n
The goal is to separate behaviors or concerns. Everything has its own place and it should be placed there.
\nBasically
\nAs opposed to Large Generic classes with different responsibilities and behaviors.
\nThis pattern can be seen in other SOLID principles like Interface Segregation where we focus on making role-specific interfaces.
\nLet’s say we are saving a random user’s data to some database. This is what we would normally do inside a function(pseudocode-ish).
\nfunction createUser(userData){\n // 1. validate user data for email and password keys\n \n // 2. check if the email is already registered\n\n // 3. save the user to DB \n\n // 4. return saved user as a response\n}With the SINGLE RESPONSIBILITY approach we will make dedicated functions that would handle specific logic and be responsible for it only
\nfunction validateUser(user){\n // will validate userObject for email and password keys\n}\n\nfunction isEmailRegistered(email){\n // will check if the email is already taken \n}\n\nfunction saveUserData(user){\n // will save user data to db\n}\n\nfunction createUser(userData){\n validateUser(userData)\n \n if(isEmailTaken(userData.email)){\n // throw some error here\n }\n\n var user = saveUserData(userData)\n \n return user\n}This is a simple example but when dealing with multiple validations and complex logic this type of approach is really handy.
\nConsider these
\nAlso when there is a time you need-to/have-to/want-to/are-forced-to make changes and have followed SINGLE RESPONSIBILITY, then it will be much quick and easy.
\nWhat if you break something or there is a bug? Well, it is Easily traceable following this principle and if you break something, you break that one thing only, not an entire system.
\nNot to mention that this rule helps a lot in the implementation of other SOLID principles like Dependency Inversion and the Liskov Substitution Principle.
\nIf you are someone that writes tests for their project then you would surely love this rule, it gives you predictable behavior and control.
\nHere it is guys, I hope I explained it in a simple and easy way. Do you use SOLID principles in your projects? Be sure to comment below.
\nLaern about Open/Close Principle Principle in 2 Minutes.
","frontmatter":{"title":"WHY YOU SHOULD BE FOLLOWING THE SINGLE RESPONSIBILITY PRINCIPLE","date":"March 28, 2021","description":"Discover the Single Responsibility Principle of SOLID design, which ensures that change in a OOP class has only one reason."}}},"pageContext":{"slug":"/blog/why-you-should-be-following-the-single-responsibility-principle/","previous":{"fields":{"slug":"/blog/top-5-node-express-boilerplates-for-building-restful-apis-in-2021/"},"frontmatter":{"title":"TOP 5 Node-Express Boilerplates For Building RESTful API's In 2021"}},"next":{"fields":{"slug":"/blog/is-the-liskov-substitution-principle-really-useful/"},"frontmatter":{"title":"Is The Liskov Substitution Principle Really Useful?"}}}},"staticQueryHashes":["2276319502"]}