SOLID — Single Responsibility Principle — Hinglish notes

2.2.4 · Coding › Design Principles

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

Common mistake Steel-man: "Single responsibility ka matlab hai ki class sirf EK kaam kare."

Kyun sahi lagta hai: "Single" ka literal matlab ek hota hai, toh ek class jo do method calls karti hai woh lagti hai jaise SRP violate ho raha hai. Log phir har cheez ko 1-method classes mein tod dete hain. Kyun galat hai: SRP reasons to change ke baare mein hai, na ki operations ki ginti ke baare mein. Ek class mein bahut saare methods ho sakte hain aur phir bhi woh ek hi actor serve kar sakti hai. Over-splitting se tiny classes ka ek chakravyuh ban jaata hai — woh apne aap mein ek bad smell hai (anaemic/shotgun-surgery design). Fix: Yeh poochho: "Yahaan change ke liye kaunsa stakeholder request karta hai?" Agar do alag roles (jaise accounting vs. DBA) dono ek hi class ko pull kar rahe hain, wahi SRP violation hai.

WHY does SRP matter? (isse ignore karne ki keemat)

Jab ek class do actors serve karti hai, toh actor A ki requested change accidentally actor B ke behaviour ko break kar sakti hai — kyunki woh code share karte hain.

Worked example Classic

Employee god-class

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

Yeh kyun dangerous hai, step by step:

calculatePay() aur reportHours() dono ek private helper regularHours() call karte hain. Kyun? DRY — unhe overtime calculation share karni thi.
Accounting overtime rules tweak karne ko kehta hai → developer regularHours() edit karta hai. Kyun problem hai? HR ki report silently same helper use karti hai.
HR ke numbers bina HR ke kehey change ho jaate hain → audit fail ho jaata hai. Kyun? Do actors, ek reason-to-change boundary cross ho gayi. SRP violated.

HOW to apply SRP (procedure kya hai)

Recall Pehle sochho (answer cover karo)

Padhne se pehle: Tum Employee class ko KHUD kaise split karoge? Recurring pattern kya hai?

Answer: Data ko policies se alag karo, har actor ko uski apni class do. Shared EmployeeData rakho; PayCalculator, HourReporter, EmployeeRepository banao.

Step-by-step refactor:

Suspect class ke methods list karo.
Har method ko uske actor ke saath tag karo (changes kaun request karta hai?).
Actor ke hisaab se group karo. Har distinct actor → uski apni class.
Shared data ko ek passive data structure mein extract karo (koi policy nahi).
Optionally ek Facade provide karo taaki callers ke paas abhi bhi ek entry point rahe.

Figure — SOLID — Single Responsibility Principle

Worked example Refactored design — Har step kyun?

// 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

Alag PayCalculator kyun? Accounting ka overtime change ab akela rehta hai; ise edit karna HR ki report ko touch nahi kar sakta.
EmployeeData passive kyun? Iske paas sirf schema ka "reason to change" hai, kisi bhi business policy ka nahi.
Facade kyun? SRP classes multiply kar sakta hai; Facade clients ke liye ek simple, akela touch-point restore karta hai jabki internals separated rehte hain.

Coupling ko quantify karne ka ek tarika (taaki tum prove kar sako)

Hum "change kitni risky hai" pe ek number daal sakte hain. Maano ek class $A$ alag-alag actors ke baare mein jaanti hai. Kisi bhi actor se ek change request ka kuch chance $p$ hai ki accidentally aise behaviour par asar ho jo doosra actor depend karta hai (shared state/helpers).

Formula Ek shared class ka cross-actor risk

Agar ek class $A$ independent actors serve karti hai aur actor pairs ka code share karna independent break-probability $p$ per change hai, toh probability hai ki koi unintended actor ek change se affected ho: $R (A) = 1 - (1 - p)^{A - 1}$ First principles se derivation:

Us actor ko fix karo jo change request karta hai. $A - 1$ baaki actors bache hain.
Ek doosre actor ke liye, not broken hone ki prob $= (1 - p)$ . (Kyun? $p$ ka complement.)
Independence ⇒ prob ki $A - 1$ mein se koi nahi broken $= (1 - p)^{A - 1}$ . (Kyun multiply? Independent events: $P (\cap) = \prod P$ .)
Prob ki kam se kam ek broken $= 1 - (1 - p)^{A - 1}$ . (Kyun? Complement rule.)

Isko padhna: $A = 1$ ⇒ $R = 0$ (SRP-clean, koi cross-actor risk nahi). $A > 1$ ⇒ risk badhta hai; yeh "ek se zyada reason to change" ka mathematical chehra hai.

Flashcards

SRP define karne wala ek phrase kya hai?

Ek class ka ek, aur sirf ek, reason to change hona chahiye.

"Reason to change" kis real-world concept se map hota hai?

Ek actor se — ek akela stakeholder/role jo changes request karta hai.

"Ek class ko sirf ek kaam karna chahiye" SRP ki galat reading kyun hai?

SRP reasons to change (actors) count karta hai, na ki operations ki ginti; ek class ke paas bahut saare methods ho sakte hain jo ek actor serve karte hain.

Employee god-class mein kaun se actors clash karte hain?

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

God-class ke liye typical SRP fix kya hai?

Ek passive data struct extract karo aur har actor ko uski apni class do; optionally Facade add karo.

Over-splitting ke baad ek single entry point restore karne wala pattern kaunsa hai?

Facade pattern.

A

actors aur break prob

p

ke liye cross-actor risk formula kya hai?

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

A = 1

R

kya hai aur kyun?

0

; ek actor ka matlab hai koi doosra actor nahi jo accidentally break ho sake.

SRP ko OVER-apply karne se kaun sa design smell aata hai?

Shotgun surgery / tiny anaemic classes ka chakravyuh.

SRP module boundaries ko kis organisational cheez ke saath align karta hai?

Stakeholders/actors ke org chart ke saath.

Recall Feynman: 12-saal ke bacche ko samjhao

Socho ek toy robot jo khana bana sakta hai, car chala sakta hai, AUR homework kar sakta hai. Agar tum robot ko spicy khana banana kaho, tum uski "cook" wires tweak karte ho — lekin woh wires "drive" wires ke saath tangled hain, toh suddenly car start nahi hogi! Yeh irritating hai. SRP kehta hai: har kaam ke liye uska apna robot do. Cooking robot, driving robot, homework robot. Ab jab tum cooking change karo, car theek se chalti rehti hai. Ek robot = ek kaam = ek reason ki koi usse change karne ko kahe.

Connections

Open-Closed Principle — jab responsibilities split ho jaati hain, tum behaviour ko bina edit kiye extend kar sakte ho.
Dependency Inversion Principle — separated responsibilities abstractions ke through baat karte hain.
Cohesion and Coupling — SRP yaani high cohesion (ek reason) + actors ke beech low coupling.
Facade Pattern — SRP ke produce kiye extra classes ko sambhalta hai.
God Object (anti-pattern) — canonical SRP violation.
Shotgun Surgery — over-splitting ka smell (SRP misapplied).
DRY Principle — savdhaan: blind DRY do actors ko ek shared helper ke zariye re-couple kar sakta hai.