Single Responsibility Principle: your code can finally breathe
Picture a restaurant where the waiter cooks, greets, cleans and does the dishes. Total chaos. Your code is the same: every class must have its own role, like in a 4-star restaurant.
That's the Single Responsibility Principle (SRP). It's part of the SOLID principles, a set of rules that turn messy code, where everything is mixed together, into clean, optimized, easily maintainable code.
Why SRP matters
Maintainability: each class has a clear, precise role.
Testability: the code is easier to test.
Reusability: components plug in easily elsewhere.
Decoupling: changes are localized and less risky.
Readability: the code becomes clearer and better organized.
The example: the catch-all UserService
Take a typical UserService class that does everything: data validation, password handling, database interactions, and sending emails. A catch-all.
With SRP, we split its responsibilities:
UserValidator: checks data consistency;PasswordManager: handles password hashing and security;UserRepository: handles database interactions;EmailService: sends and manages emails.
The result? A UserService that orchestrates these components instead of doing everything itself.
In real life
There are still countless projects with thousand-line services managing anything and everything. Every time, I think of that line: "Just because you can doesn't mean you should."
Takeaway: a service that does everything does nothing well.
This article comes from one of my LinkedIn posts (in French): join the discussion ↗