DEV Community

Understanding SOLID: Single Responsibility Principle

Tamerlan on December 13, 2020

I get it. You wanna get a job at google but your dumb ass don't know SOLID. Don't worry, Uncle T is here to help WHAT THE HELL IS SOLID?...
Collapse
 
phantas0s profile image
Matthieu Cneude

I saw too many developers (myself included) writing classes with one method each because of the SRP. That's not great. On top of that, in practice you'll have no clue who's is responsible for what in a company, and in a startup the CTO can do many, many things, for example. What do you do in that case? Create a god class?

It's more important for me to understand why the SRP was created and by what it was inspired. If you want another view on the SRP, I wrote about it here: thevaluable.dev/single-responsibil...

Collapse
 
tamerlan_dev profile image
Tamerlan

Hi, really appreciate the feedback. What your saying is indeed correct, and SRP is merely a principle that shouldn't be always followed 100% to the brim.

Collapse
 
themelis profile image
Themelis

What a great article that was Matthieu. Thank you very much!

ps: Robert Martin is really charismatic :D

Collapse
 
phantas0s profile image
Matthieu Cneude

Glad you liked it! Robert Martin is more and more controversial in the industry: some hate him, some love him. Personally, I just think his opinion is often way too absolute.

Collapse
 
nomikz profile image
nomikz

Creating a class with just a single method is totally fine for me.
Overengeenering is another talk.

Collapse
 
themelis profile image
Themelis

First of all I really liked your post and the example that you've provided.
Secondly I would like to comment on the "WHY WOULD I WANT TO DO THIS?" section. I get the feeling as I read it that whenever I implement SOLID or SRP I will always have an improvement on the code, which I don't believe is true since it get's more complicated.

As Matthieu said for example, can you imagine creating all classes with only one method? That's practically insane isn't it?

I would like to think about it like this: we don't go looking for cases to implement SOLID or SRP or any other pattern until we come to the case that we need it.

Collapse
 
nomikz profile image
nomikz • Edited

Oh deer.. Probably, you have never had to deal with maintaining huge legacy monoliths.
It is generally a good idea to follow best practices from the start. As the project grows, technical debt will start getting accumulated really fast.

Collapse
 
themelis profile image
Themelis

It's true I've never delt with huge legacy monoliths mainenance and following best practises from the start (and along the way) sounds logical to me. All I am asking: is implementing SOLID or SRP always a best practise? Aren't there cases that introduces needless complexity and overdesign (as Robert Martin states)?

Thread Thread
 
nomikz profile image
nomikz • Edited

It is good to learn good practices early on.
What is really bad is premature optimization :D

Collapse
 
ditikrushna profile image
Ditikrushna Giri

You are great at conveying things literally.