🏛️
LLD Fundamentals

SOLID Principles in LLD

Interview Mein Kahan Actually Lagte Hain
💡 SOLID principles RESTAURANT KITCHEN ke rules jaise hain — har cook ka EK kaam (SRP), naya dish add karne par purani recipe mat badlo (OCP), aur waiter ko farak nahi padna chahiye ki khana kis chef ne banaya (LSP).

LLD interview mein SOLID ka naam lena kaafi nahi hai — batana padta hai ki tumne KAHAN lagaya. SRP ka matlab hai PaymentService payment kare, notification NA bheje. OCP ka matlab hai naya VehicleType add karne par existing switch-case edit na karna pade, bas nayi class add ho.

Sabse zyada marks DIP (Dependency Inversion) se milte hain: high-level class ko CONCRETE class par nahi, INTERFACE par depend karao. BookingService ko "PaymentGateway" interface pata ho, "RazorpayGateway" nahi — tabhi test mein mock daal paoge aur kal gateway badalna 2 line ka kaam rahega.

// ❌ OCP todta hai — naya type aane par yahi method edit karna padega
double getFee(String type) {
  if (type.equals("CAR")) return 20;
  else if (type.equals("BIKE")) return 10;
}

// ✅ Naya type = nayi class, purana code chhua tak nahi
interface FeeStrategy { double fee(long hours); }
class CarFee   implements FeeStrategy { public double fee(long h) { return h * 20; } }
class BikeFee  implements FeeStrategy { public double fee(long h) { return h * 10; } }
🏛️
SOLID principles RESTAURANT KITCHEN ke rules jaise hain — har cook ka EK kaam (SRP), naya dish add karne par purani recipe mat badlo (OCP), aur waiter ko farak nahi padna chahiye ki khana kis chef ne banaya (LSP).
1 / 2
⚡ Quick Recap
  • SOLID ka naam nahi, APPLICATION batao — kahan aur kyun lagaya
  • OCP: naya feature = nayi class, purani class edit nahi
  • DIP sabse zyada valuable — interface par depend karo, concrete class par nahi
Is page mein (2 subtopics)

Single Responsibility ka asli matlab "ek class ek kaam" nahi, balki "class badalne ki EK HI WAJAH honi chahiye" hai. OrderService agar order banata hai, email bhejta hai aur invoice PDF generate karta hai — to wo teen alag-alag wajah se badlega. Teen classes honi chahiye.

Interview mein iska sabse aasaan test hai: class ka naam bolo aur usme "AND" aa jaaye to SRP toot raha hai. "OrderService order banata hai AND notification bhejta hai" — yahin galti pakdi gayi.

💡Tip: God class se bachne ka simple rule — koi bhi class 200 line se badi ho rahi ho to ruk kar socho ki kya usme do zimmedariyan mix ho gayi hain.

Dependency Inversion ka sabse bada practical fayda TESTING hai. Agar BookingService ke andar "new RazorpayGateway()" likha hai to test chalane par asli payment chala jaayega. Agar wo PaymentGateway interface constructor se leta hai, to test mein FakeGateway daal do — test fast aur safe.

Isi wajah se constructor injection ko field injection se behtar maana jaata hai: constructor dekhkar hi pata chal jaata hai ki class ko kis-kis cheez ki zaroorat hai, aur bina un dependencies ke object ban hi nahi sakta.

// ✅ Dependency bahar se aayi — test mein fake daal sakte ho
class BookingService {
  private final PaymentGateway gateway;
  BookingService(PaymentGateway gateway) { this.gateway = gateway; }
}

// Test
var service = new BookingService(new FakePaymentGateway());