Software Architecture, SOLID Principles & Design Patterns

Problem: Seller portal me feature — "package ko ek courier service se deliver karna hai." Simple code: Delivery class (method: deliver(courier)) + Courier class; main me courier object banao, delivery ko pass karo. Ab business bada hua — international courier bhi chahiye. Aasan (par galat) fix: Courier me courierType rakho aur deliver() me if national ... else international ... likho. Ye Open-Closed Principle violate karta hai — hum existing class modify kar rahe hain!

Solution: Replace direct object construction calls (new operator) with calls to a special factory method.

• Delivery aur Courier ko abstract banao.
• Har type ke liye subclasses: NationalCourier, InternationalCourier (Courier extend karte hain) aur NationalDelivery, InternationalDelivery (Delivery extend karte hain).
• Delivery me abstract method createCourier() — yehi factory method hai. NationalDelivery ka createCourier() → NationalCourier object return karta hai; InternationalDelivery ka → InternationalCourier.
• Object banane ki responsibility delegate ho gayi in classes ke factory method ko. Main me: delivery object banao, d.createCourier() bulao, jo courier mile use deliver() me do.

// Factory pattern ka core idea
abstract class Delivery {
    abstract Courier createCourier();   // ← FACTORY METHOD
    void deliver(Courier c) { ... }
}
class InternationalDelivery extends Delivery {
    Courier createCourier() { return new InternationalCourier(); }
}

Naya type (local courier) add karna ho? Bas nayi classes banao + factory method — koi existing class modify nahi hoti.

Problem: Book object banana hai — kuch parameters mandatory (ISBN, title, cost) aur kuch optional (author, published, description). Har combination ke liye alag constructor likhna padta hai — is problem ko Telescoping Constructors kehte hain (exam keyword!). Code ganda + complicated.

Solution: Extract the object construction code out of its own class and move it to a separate object called a builder.

• Builder class banao (Book ke andar static class) — same fields.
• Builder ka constructor sirf mandatory params leta hai (ISBN, title, cost).
• Har optional field ke liye alag method: author(), published(), description() — jo field set karke builder return karti hai.
• Last me build() method — final Book object return karta hai. Book ka ab ek hi constructor hai jo builder leta hai.

// step-by-step object banao
Book b1 = new Book.Builder("978-93", "SE Notes", 450)
                 .author("Iyer").published(2024).description("...")
                 .build();
Book b2 = new Book.Builder("978-94", "DSA", 300)
                 .description("desc only").build();  // baaki null

Problem: Buyer order place kare toh system ko 4 kaam karne hain: create order → notify seller → prepare packaging → send for delivery. Client ko 4 classes ke objects banane + sahi order me methods bulane padte hain. Client ko itni details kyun pata honi chahiye? Complicated library functions use karne walon ka bhi yahi dard hai.

Solution: Facade provides a simple interface to a library or a complex set of classes. Ek nayi class banao — DeliveryFacade — jiska ek method (deliver()) saare object creation + function calls apne andar kar leta hai. Client bas facade ka ek method bulaye, kaam done!

class DeliveryFacade {
    void deliver(product, sellerName) {
        new Order().placeOrder(product);
        new Seller().notifySeller(sellerName);
        new Package().packageOrder();
        new Delivery().deliverOrder();   // sab ek jagah
    }
}

Problem: Seller portal me kuch products ki cost dollars/euros me hai — rupees me conversion chahiye. Ek existing library/class hai ConversionCalculator jis par hamara control nahi hai, aur uska interface Product class ke saath incompatible hai — Product directly use nahi kar sakta.

Solution: Beech me ek adapter class daalo — ye ek wrapper hai jo client aur adaptee ke beech link provide karta hai. Client adapter ka method bulata hai → adapter andar hi andar adaptee ka (incompatible) method bulata hai. Incompatibility ka saara jhanjhat adapter handle karta hai — client ko complexity pata hi nahi chalti.

// CostCalculatorAdapter = bridge between Product & ConversionCalculator
class CostCalculatorAdapter {
    double getCostInRupees(Product p) {
        ConversionCalculator cc = new ConversionCalculator();
        return cc.dollarToRupee(p.cost);   // $300 → ₹ me convert
    }
}

Product ko ConversionCalculator ki koi detail nahi pata — woh sirf adapter se baat karta hai. (Real life analogy: charger ka plug adapter — US plug ko Indian socket me lagane wala!)

Problem: Hum alag-alag collections use karte hain — lists, queues, stacks, trees (products ki list, orders ki list, deliveries ki list...). Common operation: elements ko access aur iterate karna. Client ko sirf elements chahiye — elements kaise store hain (underlying data structure), usse client ko matlab nahi.

Solution: Elements ko access karne ka behaviour ek alag object — iterator — me nikaal do. Java ka Iterator interface ke 2 key methods:

• hasNext() — true return karta hai agar iteration me aur elements hain
• next() — iteration ka agla element return karta hai

ArrayList ho ya LinkedList — dono in methods ki apni implementation dete hain. Client ko implementation details jaanne ki zaroorat nahi; woh bas hasNext()/next() use kare. Collection badal do, client ka loop same rahega!

Problem: Naya product launch ho toh sirf subscribed buyers ko notify karna hai — saare users ko nahi. (YouTube analogy: channel subscribe + bell icon 🔔 → naya video aate hi notification.)

Solution: Subject object ek list of observers maintain karta hai; jab bhi update ho, subject saare observers ko notify kar deta hai.

• Subject class — observers ka collection; methods: registerObserver(), unregisterObserver(), notifyObservers()
• Observer — interface/abstract class with update() method
• notifyObservers() bas collection pe iterate karke har observer ka update() bula deta hai
• Lecture example: NormalUser aur PrimeUser dono Observer extend karte hain — normal user ko "naya product aaya" message, prime user ko extra "aapko additional discount bhi milega" 😎 — har type apna update() implement karta hai

Problem: Shopping orders ko alag-alag strategies se process karna hai — (a) First In First Out (FIFO): jo order pehle aaya, pehle process; (b) Priority: prime/super users ke orders pehle. Bina pattern ke: OrderManager me har strategy ka apna method (deliverFIFO(), deliverPriority()...). Nayi strategy aayi? Class me naya method add karo → OCP violated (existing class modify ho rahi hai).

Solution: Alag-alag strategies/algorithms ko separate classes me extract karo. Original class (context) algorithm ka kaam strategy object ko delegate kar deti hai.

• Interface: OrderDeliveryStrategy — method deliverOrders()
• FIFOOrderDelivery aur PriorityOrderDelivery — dono interface implement karte hain, apna-apna logic deliverOrders() me
• Runtime pe strategy switch kar sakte ho: pehle FIFO se deliver kiya, phir priority se — bas naya strategy object do
• Nayi strategy? Nayi class banao jo interface implement kare — existing code me zero changes ✅