Design Patterns for LLD
23 GoF patterns ratne ki zaroorat NAHI hai. LLD interviews mein practically 6 hi baar-baar aate hain: STRATEGY (badalta hua behaviour — pricing, parking fee), FACTORY (object creation — vehicle, notification channel), SINGLETON (ek hi instance — logger, config), OBSERVER (event par multiple reaction — order placed), STATE (object ka behaviour uski state par depend kare — vending machine, elevator), aur BUILDER (bahut saare optional fields — booking request).
Pattern ZABARDASTI mat thopo. Agar 2 hi vehicle types hain aur kabhi nahi badlenge, to Strategy over-engineering hai. Interviewer over-engineering ko utna hi negative marks deta hai jitna under-engineering ko. Bolo — "abhi 2 types hain to simple rakh raha hoon, 5+ hue to Strategy mein nikaal doonga."
// STATE — vending machine ka behaviour uski state se decide hota hai
interface VendingState {
void insertCoin(Machine m);
void selectItem(Machine m, String code);
}
class IdleState implements VendingState {
public void insertCoin(Machine m) { m.setState(new HasMoneyState()); }
public void selectItem(Machine m, String c) {
throw new IllegalStateException("Pehle paise daalo");
}
}
// Naya state add karna = nayi class, purane states untouched- Strategy, Factory, Singleton, Observer, State, Builder — 90% LLD yahi cover karte hain
- Pattern trigger pehchano, pattern ratna mat
- Over-engineering bhi galti hai — simple solution defend karna aata hona chahiye
Dono dikhne mein same lagte hain (dono interface + implementations hain) par IRAADA alag hai. STRATEGY mein algorithm BAHAR se choose hota hai aur objects ek doosre ko nahi jaante — jaise FeeStrategy. STATE mein object KHUD apna agla state set karta hai — jaise IdleState khud HasMoneyState par switch karta hai.
Aasaan pehchaan: agar transitions ka gyaan implementations ke andar hai to wo STATE hai; agar bahar se inject ho raha hai to STRATEGY hai.
Singleton logger, config aur connection pool ke liye theek hai. Par har jagah Singleton lagana ANTI-PATTERN hai — wo global state banata hai, testing mushkil kar deta hai, aur hidden dependency paida karta hai.
Agar Singleton use karo to thread-safe banao. Java mein sabse saaf tareeka ENUM singleton hai — JVM khud guarantee deta hai ki ek hi instance banega, aur serialization/reflection se bhi toota nahi ja sakta.
// Sabse safe singleton — thread safety JVM guarantee karta hai
enum ConfigManager {
INSTANCE;
private final Map<String, String> config = loadConfig();
public String get(String key) { return config.get(key); }
}