For those of you already familiar with the SOLID Design Principles, this won't be much of a new thing. For newbies however
SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.
They are more like best practices rather than a rule.
SINGLE RESPONSIBILITY
The S in SOLID.
It says
A class should have one, and only one reason to change.
The goal is to separate behaviors or concerns. Everything has its own place and it should be placed there.
Basically
- Make smaller code modules (class/function etc)
- Module does a specific thing only and is liable for that only.
- It is named precisely for what it does.
As opposed to Large Generic classes with different responsibilities and behaviors.
This pattern can be seen in other SOLID principles like Interface Segregation where we focus on making role-specific interfaces.
A SIMPLE USE CASE
Let'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).
function createUser(userData){
// 1. validate user data for email and password keys
// 2. check if the email is already registered
// 3. save the user to DB
// 4. return saved user as a response
}
With the SINGLE RESPONSIBILITY approach we will make dedicated functions that would handle specific logic and be responsible for it only
function validateUser(user){
// will validate userObject for email and password keys
}
function isEmailRegistered(email){
// will check if the email is already taken
}
function saveUserData(user){
// will save user data to db
}
function createUser(userData){
validateUser(userData)
if(isEmailTaken(userData.email)){
// throw some error here
}
var user = saveUserData(userData)
return user
}
This is a simple example but when dealing with multiple validations and complex logic this type of approach is really handy.
WHY USE IT
Consider these
- Easy to follow and Understand
- Debugging made easy
- Removing and refactoring is much simpler than before.
- You can make bigger changes without fear.
- It is scalable and maintainable
Also 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.
What 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.
Not to mention that this rule helps a lot in the implementation of other SOLID principles like Dependency Inversion and the Liskov Substitution Principle.
Tip
If you are someone that writes tests for their project then you would surely love this rule, it gives you predictable behavior and control.
Here 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.
What's Next
Laern about Open/Close Principle Principle in 2 Minutes.
Top comments (9)
Now, one reason NOT to use SOLID. It looks good from the outside 99% of the time. But take another look at your example code. You've now introduced a race condition in your code between checking if an email address is already used, and then saving the new user data.
As someone that has done enterprise software engineering for ~15 years, these are now the sorts of things I look out for and have to engineer against. So when you see some more funky code, take a step back and ask "why is it done this way with this level of complexity?" - because more often then not, there are real world problems that need to be solved that cannot entirely be met with these ideals in mind.
I don’t see a new race condition. The simple fact some code has been segregated to functions doesn’t introduce something new. That code won’t run in parallel by merely calling the methods in sequence so that one thing could get executed out of order and without waiting.
It isn't because of separating them out into individual functions. It is that there could be multiple invocations at once, for instance two users attempting to register at the same time with competing information. And its because of situations like this why some code is written in a more complex way to handle these situations.
I guess if it is put in a step-wise class; where the order is obeyed. There shouldn't be a problem. We give this user flow exclusive access to these functions. Layout like this in the article would give headache if used inappropriately.
Yeah, but that’s not because the code gets split in functions. The exact same thing applies to the original code.
That’s a whole different discussion beyond the point of illustrating a concept.
I appreciate your suggestion. I have a question and correct me if I am wrong, Does the Race Condition or Data Race also occur in single thread programs/code?
If there is truly only one invocation possible at a time, then yes, that is fine. But that simply isn't scalable. If we're looking at a web application or API for instance, multiple users would be using the site at the same time.
The Single Responsibility Principle by Robert C. Martin (~2010):
YouTube
See also The Single Responsibility Principle (2014).
Great explanation, Huzaifa! Yeah, I always use it because it's also better to test :)