SOLID — Dependency Inversion Principle — Hinglish notes

2.2.8 · Coding › Design Principles

WHAT is the Dependency Inversion Principle?

WHY does it matter?

HOW: deriving it from first principles

Chalo is principle ko change ke baare mein reasoning karke derive karte hain.

Step 1 — Natural coupling observe karo. Ek normal call graph:

OrderService → calls → MySqlOrderDb (concrete)

Yeh step kyun? Hum dekhna chahte hain ki dependency arrow by default kahan point karta hai: high-level ek concrete detail par depend karta hai.

Step 2 — Pucho: kaunsa part zyada valuable / zyada stable hai? OrderService (policy) business asset hai; MySqlOrderDb ek swappable mechanism hai.

Yeh step kyun? DIP fundamentally stable cheez ko volatile cheez se protect karne ke baare mein hai.

Step 3 — Ek abstraction insert karo jo high-level module ke paas ho. OrderRepository (interface) define karo. Ab:

OrderService → OrderRepository (interface) ← MySqlOrderDb (implements)

Yeh step kyun? Ab dono modules abstraction par depend karte hain; concrete detail ka arrow invert hokar upar point karta hai.

Step 4 — Concrete ko injection ke through supply karo. Constructor ke through concrete object do (Dependency Injection common delivery mechanism hai).

Yeh step kyun? High-level module ko kabhi concrete ko new nahi karna chahiye — warna source-code dependency wapas aa jaati hai.

Figure — SOLID — Dependency Inversion Principle

Worked example Bad → Good (Java-ish pseudocode)

DIP violate karta hai — high-level concrete par depend karta hai:

class NotificationService {
    EmailSender sender = new EmailSender(); // concrete!
    void notify(String m){ sender.sendEmail(m); }
}

Kyun bura hai? NotificationService (policy) EmailSender (detail) se judi hui hai. SMS add nahi kar sakte ya real email bheje bina unit-test nahi kar sakte.

DIP follow karta hai:

interface MessageSender { void send(String m); }       // abstraction (owned by policy)
class EmailSender implements MessageSender { ... }      // detail points UP
class SmsSender   implements MessageSender { ... }

class NotificationService {
    private final MessageSender sender;
    NotificationService(MessageSender s){ this.sender = s; } // injected
    void notify(String m){ sender.send(m); }
}

Kyun accha hai? Ab notify kisi bhi sender ke saath kaam karta hai; channels badalna kabhi business logic ko touch nahi karta; tests ek FakeSender pass karte hain.

Common mistake Common confusions ko steel-man karna

Mistake 1: "DIP ka matlab sirf Dependency Injection use karna hai." Kyun sahi lagta hai: DI hi woh tarika hai jisse hum abstraction deliver karte hain, isliye dono same lagte hain. Fix: DI ek technique hai (object pass karna). DIP ek goal hai (abstractions par depend karo). Tum ek concrete class inject kar ke bhi DIP violate kar sakte ho; aur service locator ya factory se classic DI ke bina bhi DIP satisfy kar sakte ho.

Mistake 2: "Sab kuch abstract karo — har class ko interface mein wrap karo." Kyun sahi lagta hai: Zyada interfaces zyada flexible lagti hain. Fix: Abstractions indirection ka cost laati hain. DIP volatile boundaries par apply karo (DB, network, UI, 3rd-party libs) — woh jagahein jo change hone ki zyada sambhavna rakhti hain. Stable, simple value classes ko iski zarurat nahi (80/20: zyaadatar benefit kuch key seams ko invert karne se milta hai).

Mistake 3: "Interface low-level package mein rehni chahiye." Kyun sahi lagta hai: Implementer DB code hai, isliye contract us ke paas rakho. Fix: Abstraction ko high-level policy ke paas / uske near rehna chahiye. Yahi cheez dependency ko truly inverted banati hai — detail package, policy package par depend karta hai, na ki ulta.

Recall Feynman: ek 12-saal ke bacche ko explain karo

Tumhare paas ek toy robot hai. Ek specific battery andar glue karne ki bajaye, tumne use ek standard size ka battery slot diya. Ab tum koi bhi battery daal sakte ho — rechargeable, regular, ya solar pack — bas slot mein fit honi chahiye. Robot sirf "woh cheez jo slot mein fit hoti hai" jaanta hai, exact battery nahi. Tum robot ko khole aur rebuild kiye bina batteries hamesha ke liye badal sakte ho. "Slot ki shape" abstraction hai; robot tumhara important code hai; batteries swappable details hain.

Active Recall

What are the two clauses of the Dependency Inversion Principle?

(1) High-level aur low-level modules dono ko abstractions par depend karna chahiye, ek doosre par nahi. (2) Abstractions ko details par depend nahi karna chahiye; details ko abstractions par depend karna chahiye.

What does "inversion" refer to in DIP?

Dependency arrow ko flip karna: high-level code ke concrete low-level class par depend karne ki bajaye, dono ek aisi abstraction par depend karte hain jo high-level module ke paas hoti hai — isliye detail ka arrow UPAR point karta hai.

Difference between DIP and Dependency Injection?

DIP ek design goal hai (abstractions par depend karo); DI ek technique hai dependency deliver karne ki. Tum DI use kar ke bhi concrete inject kar sakte ho aur DIP violate kar sakte ho.

Which letter of SOLID is DIP?

The "D" (last one).

Where should the abstraction (interface) ideally live?

High-level policy module ke paas/near, jo ise own karta hai, taaki low-level detail package, policy package par depend kare — dependency truly inverted ban sake.

Define instability I in terms of couplings.

I = Ce / (Ca + Ce); I=0 maximally stable hai (kisi par depend nahi karta), I=1 maximally unstable hai.

Why shouldn't you wrap every class in an interface?

Abstractions indirection ka cost laati hain; DIP ko volatile boundaries (DB, network, UI, 3rd-party) par apply karo — 80/20, har jagah nahi.

What practical benefit does DIP give for testing?

Tum abstraction ki ek fake/mock implementation inject kar sakte ho, aur business logic ko real DB/email/network ke bina test kar sakte ho.

Connections

SOLID — Single Responsibility Principle
SOLID — Open-Closed Principle (DIP hi woh tarika hai jisse tum boundaries par OCP achieve karte ho)
SOLID — Liskov Substitution Principle (substitutability inversion ko safe banata hai)
SOLID — Interface Segregation Principle
Dependency Injection
Strategy Pattern / Factory Pattern
Inversion of Control Containers
Coupling and Cohesion
Hexagonal Architecture / Ports and Adapters