SOLID — Single Responsibility Principle

WHAT is the Single Responsibility Principle?

The "S" in SOLID:

S — Single Responsibility ← this note
O — Open/Closed
L — Liskov Substitution
I — Interface Segregation
D — Dependency Inversion

WHY does SRP matter? (the cost of ignoring it)

When one class serves two actors, a change requested by actor A can accidentally break behaviour relied on by actor B — because they share code.

Worked example The classic

Employee god-class

class Employee {
    double calculatePay()   { ... }  // owned by Accounting
    String reportHours()    { ... }  // owned by HR / Operations
    void   save()           { ... }  // owned by DBA
}

Why this is dangerous, step by step:

calculatePay() and reportHours() both call a private helper regularHours(). Why? DRY — they shared the overtime calculation.
Accounting asks to tweak overtime rules → developer edits regularHours(). Why a problem? HR's report silently uses the same helper.
HR's numbers now change without HR asking → audit fails. Why? Two actors, one reason-to-change boundary crossed. SRP violated.

HOW to apply SRP (the procedure)

Recall Forecast first (cover the answer)

Before reading: How would YOU split the Employee class? What's the recurring pattern?

Answer: Separate the data from the policies, giving each actor its own class. Keep the shared EmployeeData; create PayCalculator, HourReporter, EmployeeRepository.

Step-by-step refactor:

List the methods of the suspect class.
Tag each method with its actor (who requests changes to it?).
Group by actor. Each distinct actor → its own class.
Extract shared data into a passive data structure (no policy).
Optionally provide a Facade so callers still have one entry point.

Figure — SOLID — Single Responsibility Principle

Worked example Refactored design — Why each step?

// passive data — changes only if the data model changes (one reason)
class EmployeeData { String name; int hoursWorked; double rate; }
 
class PayCalculator    { double calculatePay(EmployeeData e){...} } // Accounting
class HourReporter     { String reportHours(EmployeeData e){...} }  // HR
class EmployeeRepository { void save(EmployeeData e){...} }         // DBA
 
class EmployeeFacade { /* delegates to the three above */ }         // convenience

Why a separate PayCalculator? Accounting's overtime change now lives alone; editing it cannot touch HR's report.
Why EmployeeData passive? It has only the "reason to change" of the schema, not of any business policy.
Why a Facade? SRP can multiply classes; the Facade restores a single, simple touch-point for clients while keeping internals separated.

A way to quantify the coupling (so you can prove it)

We can put a number on "how risky is a change." Let a class be touched by $A$ different actors. A change request from any actor has some chance $p$ of accidentally affecting behaviour another actor depends on (shared state/helpers).

Formula Cross-actor risk of a shared class

If a class serves $A$ independent actors and each pair of actors shares code with independent break-probability $p$ per change, the chance that some unintended actor is affected by one change is: $R(A) = 1 - (1-p)^{\,A-1}$ Derivation from first principles:

Fix the actor who requests the change. There remain $A-1$ other actors.
For one other actor, prob of not being broken $= (1-p)$ . (Why? complement of $p$ .)
Independence ⇒ prob none of the $A-1$ are broken $= (1-p)^{A-1}$ . (Why multiply? independent events: $P(\cap) = \prod P$ .)
Prob at least one broken $= 1 - (1-p)^{A-1}$ . (Why? complement rule.)

Reading it: $A=1$ ⇒ $R=0$ (SRP-clean, no cross-actor risk). $A>1$ ⇒ risk grows; this is the mathematical face of "more than one reason to change."

Flashcards

What single phrase defines SRP?

A class should have one, and only one, reason to change.

"Reason to change" maps to what real-world concept?

An actor — a single stakeholder/role that requests changes.

Why is "a class should do only one thing" a wrong reading of SRP?

SRP counts reasons to change (actors), not number of operations; a class can have many methods serving one actor.

In the Employee god-class, what actors collide?

Accounting (calculatePay), HR/Ops (reportHours), and DBA (save).

What is the typical SRP fix for a god-class?

Extract a passive data struct and give each actor its own class; optionally add a Facade.

What pattern restores a single entry point after over-splitting?

The Facade pattern.

Cross-actor risk formula for

A

actors, break prob

p

R(A)=1-(1-p)^{A-1}

What is

R

when

A=1

and why?

0

; one actor means no other actor to accidentally break.

Which design smell comes from OVER-applying SRP?

Shotgun surgery / a maze of tiny anaemic classes.

SRP aligns module boundaries with what organisational thing?

The org chart of stakeholders/actors.

Recall Feynman: explain to a 12-year-old

Imagine one toy robot that can cook dinner, drive a car, AND do homework. If you ask the robot to cook spicy food, you tweak its "cook" wires — but those wires are tangled with the "drive" wires, so suddenly the car won't start! That's annoying. SRP says: give each job to its own robot. The cooking robot, the driving robot, the homework robot. Now when you change cooking, the car still works fine. One robot = one job = one reason someone tells it to change.

Connections

Open-Closed Principle — once responsibilities are split, you extend behaviour without editing.
Dependency Inversion Principle — separated responsibilities talk through abstractions.
Cohesion and Coupling — SRP is high cohesion (one reason) + low coupling between actors.
Facade Pattern — tames the extra classes SRP produces.
God Object (anti-pattern) — the canonical SRP violation.
Shotgun Surgery — the smell from over-splitting (SRP misapplied).
DRY Principle — caution: blind DRY can re-couple two actors via a shared helper.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, Single Responsibility Principle ka matlab simple hai: ek class ke paas sirf ek hi reason hona chahiye change hone ka. Yahan "reason to change" ka matlab hai ek actor — yaani ek stakeholder ya role jo aapse change maangta hai. Jaise Accounting ek actor hai, HR doosra actor, aur DBA teesra. Agar ek hi class teeno ko serve kar rahi hai, toh dikkat yeh hai ki jab Accounting koi change maangega, toh shared code ki wajah se HR ka report chupke se badal sakta hai — bina HR ke kuch maange! Yeh bug nahi, design ki galti hai.

Bahut log galti karte hain ki "single responsibility" ka matlab samajhte hain "class sirf ek hi kaam kare, ek hi method ho." Yeh galat hai. Ek class ke 10 methods ho sakte hain aur phir bhi SRP follow kar sakti hai — bas un sabko ek hi actor serve karna chahiye. Asli test yeh hai: "is method ko change kaun maangega?" Agar do alag-alag log/department ek hi class ko pull kar rahe hain, tabhi SRP toot-ta hai.

Fix kaise karein? God-class ke methods ki list banao, har method ke saamne uska actor likho, phir actor ke hisaab se groups banao. Har group ko apni alag class do, aur shared data ko ek passive EmployeeData jaisi struct me daal do. Agar bahut saari choti classes ban jaayein, toh ek Facade laga do taaki bahar se ek hi simple entry point dikhe. Maine note me ek chhota formula bhi diya — $R = 1-(1-p)^{A-1}$ — jo batata hai ki jitne zyada actor ek class me, utna zyada accidentally break hone ka risk. $A=1$ pe risk zero. Yeh maths SRP ko prove kar deta hai, sirf "best practice" nahi rehta.

SOLID — Single Responsibility Principle

WHAT is the Single Responsibility Principle?

WHY does SRP matter? (the cost of ignoring it)

HOW to apply SRP (the procedure)

A way to quantify the coupling (so you can prove it)

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Design Principles

Connections