Single Responsibility Software Principle
The Single Responsibility Principle aims to make code — which becomes rigid (impossible to reuse) and fragile (a change in one place breaks something else) when dependency management goes wrong — more modular.
As Uncle Bob puts it: gather together the things that change for the same reason, and separate the things that change for different reasons.
The more responsibilities we pile onto a class, the more often it has to change. And that means even a tiny update ends up costing more and more, until our code starts actively resisting change.
Our goal isn't to shrug and say "it works, don't touch it" — it's to shrink our responsibilities down so the code can adapt to change easily.
So what does that actually mean in practice? Let's look at an example.
public class Fatura{ public void FaturaEkle() { // İş Kuralları } public void FaturaSil() { // İş Kuralları } public void RaporHazirla() { // İş Kuralları } public void EmailGonder() { // İş Kuralları }}Our FaturaEkle() (AddInvoice) method is only responsible for adding an invoice to the system, FaturaSil() (DeleteInvoice) is only responsible for deleting invoices, and the same goes for RaporHazirla() (PrepareReport) and EmailGonder() (SendEmail).
On their own, we could say each of these methods satisfies the single responsibility principle. But look at the Fatura (Invoice) class as a whole, and you'll see it's juggling several unrelated responsibilities — which violates the principle.
So what do we need to do here?
Since FaturaEkle() and FaturaSil() deal with the same kind of functionality, it makes sense to keep them together in one class.
RaporHazirla() and EmailGonder(), on the other hand, are completely independent and serve entirely different purposes — pulling them out into their own separate classes is exactly what satisfies the single responsibility principle.
Let's fix it right now!
public class Fatura{ public void FaturaEkle() { // İş Kuralları } public void FaturaSil() { // İş Kuralları }}public class Rapor{ public void RaporHazirla() { // İş Kuralları }} public class Email{ public void EmailGonder() { // İş Kuralları }}And that's it!
Now every class has exactly one responsibility, and exactly one reason to change. The code is smaller and easier to manage for each piece of functionality. So whenever you need to change something, you no longer have to understand — or test — the entire class just to touch one part of it.
Working this way makes our code far easier to control, and it also boosts reusability.
SUMMARY
Now we understand how to restructure code to reach the Single Responsibility Principle. It helps us cut down on complexity and makes our code much easier to maintain.
Grateful that you read this.
Take care, friends...
To keep going with the SOLID principles, check out the Open/Closed Principle:
👉 Open-Closed Principle (OCP) — SOLID
References:
What is Single Responsibility Principle (Important)
