SOLID — Interface Segregation Principle — Hinglish notes

2.2.7 · Coding › Design Principles

YE HAI KYA?

Yahan client ka matlab hai wo code jo interface par depend karta hai — caller BHI aur implementer BHI. Jab ek interface unrelated capabilities ko bundle karta hai, toh har implementer un sab mein ghich jaata hai.

YE EXIST KYUN KARTA HAI?

Fat interfaces ke teen concrete pains:

Forced dummy implementations → dead code, type system mein jhooth.
Coupling by accident — eat() ka signature change karo aur har worker recompile hoga, robots bhi.
Misleading contracts — callers trust nahi kar sakte ki koi method actually kaam karti hai.

KAISE APPLY KAREIN

Figure — SOLID — Interface Segregation Principle

Worked Example 1 — Classic Robot

Worked example ISP ka violation

interface Worker {
    void work();
    void eat();   // not all workers eat!
}
 
class RobotWorker implements Worker {
    public void work() { /* assemble cars */ }
    public void eat()  { throw new UnsupportedOperationException(); } // ❌ lie
}

Ye bura kyun hai? RobotWorker ko eat() par depend karne ke liye force kiya ja raha hai. Koi bhi code jo robot par worker.eat() call karta hai wo runtime par crash karta hai — compiler warn nahi kar sakta tha.

Worked example ISP se fix kiya

interface Workable { void work(); }
interface Feedable { void eat(); }
 
class HumanWorker implements Workable, Feedable {
    public void work() { ... }
    public void eat()  { ... }
}
class RobotWorker implements Workable {   // ✅ only what it needs
    public void work() { ... }
}

Ye step kyun? Ek canteen scheduler ab sirf Feedable par depend karta hai. Ye RobotWorker ko refer bhi nahi kar sakta, toh bug class compile time par hi gayab ho jaati hai.

Worked Example 2 — Multifunction Printer

Worked example Fat interface

interface Machine {
    void print(Doc d);
    void scan(Doc d);
    void fax(Doc d);
}

Ye kyun fail karta hai: Ek OldPrinter jo sirf print kar sakta hai use fir bhi scan aur fax implement karne padenge. Aur bura, Machine mein koi nayi method add karo (jaise staple()) toh har machine break ho jaayegi.

Worked example Segregated

interface Printer { void print(Doc d); }
interface Scanner { void scan(Doc d); }
interface Fax     { void fax(Doc d); }
 
class OldPrinter implements Printer { ... }
class AllInOne  implements Printer, Scanner, Fax { ... }

Ye step kyun? Roles ka composition. OldPrinter ka contract ab honest hai, aur staple() ko interface Stapler ke roop mein add karna kisi ko touch nahi karta jo staple nahi karta.

Worked Example 3 — Win measure karna

Common Mistakes (Steel-manned)

Recall Feynman: ek 12-saal ke bachche ko samjhao

Socho ek restaurant menu jo tumhe force karta hai soup, salad AUR dessert saath order karne ke liye, chahe tumhe sirf soup chahiye. Annoying hai, na? Ek achha menu tumhe sirf jo chahiye wo pick karne deta hai. Ek interface ek menu hai un cheezeon ka jo ek piece of code kar sakta hai. ISP kehta hai: code ko aisi abilities "order" karne ke liye force mat karo jo kabhi use nahi hogi — use sirf apni dishes wala chhota menu do.

Active Recall

SOLID mein I ka kya matlab hai?

Interface Segregation Principle.

Interface Segregation Principle state karo.

Kisi bhi client ko aisi methods (interface members) par depend karne ke liye force nahi karna chahiye jo wo use nahi karta.

Code mein ISP violation ka core symptom kya hai?

Implementers empty/dummy methods likhte hain ya un methods ke liye UnsupportedOperationException throw karte hain jo wo use nahi karte.

"Role interface" kya hota hai?

Ek chhota interface jo us hisaab se define hota hai ki ek specific client ko kya chahiye, sirf cohesive methods ko group karta hai jo saath use hote hain.

ISP fix: fat interface ko kis criterion se split karein?

Cohesive client role/need se — individual method se NAHI (over-splitting avoid karo).

ISP aur SRP mein kya fark hai?

SRP ek class ke reasons to change ko limit karta hai; ISP limit karta hai ki ek client kya depend karne ke liye force hota hai. ISP "interfaces ke liye SRP" hai.

m methods aur implementer i ke u_i use karne par, fat interface kitni forced dependencies impose karta hai?

i ke over sum of (m - u_i); segregation ise 0 tak reduce karta hai.

Kaunsa doosra SOLID principle violate hota hai jab ek interface method ko exception ke saath stub kiya jaata hai?

Liskov Substitution Principle (subtype supertype ka contract tod deta hai).

Connections

SOLID — Single Responsibility Principle — ISP, SRP ko interfaces par apply karna hai.
SOLID — Liskov Substitution Principle — dummy stubs jo throw karte hain wo LSP violate karte hain.
SOLID — Dependency Inversion Principle — chhote role interfaces depend karne ke liye ideal abstractions hain.
Cohesion and Coupling — ISP cohesion badhata hai, coupling ghataata hai.
Design Patterns — Adapter — adapters aksar segregated interfaces ke beech translate karte hain.