DEV Community

Cover image for SOLID: Single Responsibility Principle With Examples

SOLID: Single Responsibility Principle With Examples

Gopi Gorantala on July 23, 2023

In this article, you will learn about the following: What is SRP? Importance of SRP in software development Strengths Weaknesses Twitter Registra...
Collapse
 
titaniumcoder477 profile image
James Wilmoth

Nice breakdown, thanks!

Collapse
 
krishna_bhaskar_2d8c2dd1c profile image
Bhaskar L

Nice article.

Collapse
 
catsarebetter profile image
Hide Shidara

Great stuff! solid!

Collapse
 
david_kariuki profile image
David Kariuki

Great article

Collapse
 
roksoftwaretr profile image
Rok Software

thank you :)

Collapse
 
devlinaung profile image
Lin Aung

Good Article, thanks!

Collapse
 
nimmneun profile image
Stefan

Sometimes, overly simplified examples can lead to adopters creating a bit of a mess in larger projects. E.g. having a dozen different services with a single public method each for password reset, registration, deletion, login, password update, profile update, etc ...

And naming things is hard sometimes. People name things differently. What's the difference between this ForgotPassword component and the ResetPassword component? Oh there's also a PasswordReset component here? Did we implement the same thing N times?

And User/Account stuff is still fairly simple and well understood. It does get more messy and out of hand in other areas.

Personally I tend hide/aggregate things through a facade nowadays. Similar to how you would do it with a public package/lib you publish. You only expose one (best case xD) or very few classes/functions to a dev using your package. And the package hopefully does one thing well e.g. Handle User/Account related stuff.

Just don't have me type UserService and my IDE suggest 50 different classes 😅

Collapse
 
pabzt profile image
Daniel Stoll

yet another developer writing about SRP and didn't understand it...

The common misconception about the Single Responsibility Principle is that it means a class should only do one thing or have only one functionality. Under this interpretation, developers often oversimplify their classes, leading to a large number of classes, each performing a very specific, narrow function. This could lead to an overly fragmented system which can be difficult to navigate and maintain.

However, Uncle Bob explains that the SRP is not about classes doing one thing, but rather about classes having one, and only one, reason to change. That reason to change is tied to a single actor or a single user group who would request that change. As such, the responsibility is defined in terms of the actor, not the functionality.

Here's a quote from "Clean Architecture" that clarifies the SRP:

"Gather together the things that change for the same reasons. Separate those things that change for different reasons."

This is a much more nuanced interpretation and is often more practical in real-world software development. A single class can have multiple methods and properties, as long as they all would change for the same reason, i.e., the same actor.

Collapse
 
tandrieu profile image
Thibaut Andrieu

Yet another person who created an account for the sole purpose of contradicting the author. Cunningham's law is strong with you man 😉.
Anyway, I agree with you.

Collapse
 
ggorantala profile image
Gopi Gorantala • Edited

@pabzt, check out this example - ggorantala.dev/srp-examples/.

Collapse
 
zoongit profile image
zoongit

I think what he meant is the implementation should use interfaces.
Check out this Single Responsibility Principle | Object Oriented Design
https://www.oodesign.com/single-responsibility-principle