Scenario: shipping cost is computed differently per carrier (flat, weight-based, zone-based). Baking all three into one method with a switch means editing it for every new carrier. Strategy makes each algorithm a separate interchangeable object, injected into the context: new Checkout(new WeightBasedShipping()).

परिस्थिती: shipping खर्च प्रति carrier वेगळा मोजला जातो (flat, weight-based, zone-based). तिन्ही एका method मध्ये switch ने कोंबणं म्हणजे प्रत्येक नव्या carrier साठी ती edit करणं. Strategy प्रत्येक algorithm ला वेगळा interchangeable object करतं, context मध्ये injected: new Checkout(new WeightBasedShipping()).

   Checkout(context) ──► «ShippingStrategy.cost(order)»
                                 ▲          ▲          ▲
                          FlatRate   WeightBased   ZoneBased
   swap at runtime: checkout.setStrategy(new ZoneBased())
   add a carrier → new class implementing the interface. context unchanged.

interface ShippingStrategy { cost(order: Order): Money }
class FlatRate     implements ShippingStrategy { cost(o){ return Money.of(5,'USD') } }
class WeightBased  implements ShippingStrategy { cost(o){ return Money.of(o.weightKg*2,'USD') } }
class ZoneBased    implements ShippingStrategy { cost(o){ /* by destination */ } }

class Checkout {
  constructor(private shipping: ShippingStrategy) {}   // the strategy is injected
  quote(order: Order){ return order.total().add(this.shipping.cost(order)) }
}
new Checkout(new WeightBased()).quote(order)     // pick per carrier at runtime
// in JS you'd often just pass a function: (order) => Money.of(order.weightKg*2,'USD')

Scenario: when an order ships, several things must react — email the customer, update analytics, notify the warehouse — and you'll keep adding reactions. Hard-coding all of them into ship() couples it to everything. Observer lets the order publish an event and any number of subscribers react, without the publisher knowing who's listening.

परिस्थिती: order ship होताच अनेक गोष्टींनी प्रतिक्रिया द्यावी — customer ला email, analytics update, warehouse ला सूचना — आणि तुम्ही आणखी प्रतिक्रिया जोडत राहाल. त्या सगळ्या ship() मध्ये hardcode करणं त्याला सगळ्याशी जोडतं. Observer order ला एक event publish करू देतं आणि कितीही subscribers प्रतिक्रिया देतात, publisher ला कोण ऐकतंय हे न कळता.

   Order.ship()  ──emit('shipped')──►  observers notified:
                                          ├─ EmailObserver.on(e)   → send email
                                          ├─ AnalyticsObserver.on(e)→ track
                                          └─ WarehouseObserver.on(e)→ update stock
   the Order doesn't know who's listening. add/remove observers without touching it.

type Handler<T> = (event: T) => void
class Subject<T> {
  private observers = new Set<Handler<T>>()
  subscribe(h: Handler<T>){ this.observers.add(h); return () => this.observers.delete(h) } // returns unsubscribe
  notify(event: T){ this.observers.forEach(h => h(event)) }
}
const shipped = new Subject<Order>()
shipped.subscribe(o => mailer.sendShipped(o))       // add reactions freely,
shipped.subscribe(o => analytics.track('shipped', o)) // without editing the publisher
// on ship: shipped.notify(order)

Scenario: you need undo/redo in an editor, and a background job queue where work runs later on another machine. Both need the same thing: an action turned into an object you can store, pass around, queue, log, and replay. That's the Command pattern — encapsulate "do this" (and often "undo this") as a first-class object.

परिस्थिती: तुम्हाला editor मध्ये undo/redo हवं, आणि background job queue जिथे काम नंतर दुसऱ्या machine वर चालतं. दोघांना तीच गोष्ट लागते: object मध्ये बदललेली क्रिया जी तुम्ही साठवू, पास करू, queue करू, log करू, आणि replay करू शकता. हाच Command pattern — 'हे कर' (आणि अनेकदा 'हे undo कर') एक first-class object म्हणून encapsulate करा.

   «Command { execute()  undo() }»
        ├─ ChargeCard(order, amount)     ─► queue → run on a worker later
        ├─ AddItem(cart, product)        ─► push on undo-stack; undo() reverses it
        └─ SendEmail(to, template)       ─► log → retry on failure
   invoker just calls cmd.execute(); it doesn't know WHAT the command does

interface Command { execute(): void; undo(): void }

class AddItem implements Command {                      // an action as an object
  constructor(private cart: Cart, private product: Product) {}
  execute(){ this.cart.add(this.product) }
  undo(){ this.cart.remove(this.product) }
}
class History {                                         // invoker + undo stack
  private done: Command[] = []
  run(c: Command){ c.execute(); this.done.push(c) }
  undo(){ this.done.pop()?.undo() }
}
// queue variant: serialize commands and run them on a worker later (job queue)

Scenario: an incoming HTTP request must pass through auth, rate-limiting, logging, and body-parsing before reaching your handler — and each step may pass it on or stop it. Chain of Responsibility links handlers so a request flows down the chain until one handles it (or all get a turn). This is web middleware.

परिस्थिती: येणाऱ्या HTTP request ने तुमच्या handler पर्यंत पोहोचण्याआधी auth, rate-limiting, logging, आणि body-parsing मधून जायला हवं — आणि प्रत्येक step ते पुढे देऊ किंवा थांबवू शकतो. Chain of Responsibility handlers जोडतं म्हणजे request रांगेतून खाली वाहते जोपर्यंत कुणी हाताळत नाही (किंवा सगळ्यांना संधी मिळते). हेच web middleware.

   request ─► Auth ─► RateLimit ─► Logging ─► BodyParser ─► Handler
                │         │  (429?     │ next()      │            │
              next()   stop!)        next()        next()      respond
   any link can handle-and-stop or transform-and-forward. reorder freely.

type Ctx = { req: Request; res: Response }
type Handler = (ctx: Ctx, next: () => void) => void

function chain(handlers: Handler[]) {
  return (ctx: Ctx) => {
    let i = -1
    const dispatch = () => { i++; if (i < handlers.length) handlers[i](ctx, dispatch) }
    dispatch()
  }
}
const auth: Handler      = (c, next) => c.req.user ? next() : c.res.status(401)  // stop
const rateLimit: Handler = (c, next) => underLimit(c) ? next() : c.res.status(429)
const app = chain([auth, rateLimit, /* logging, */ handler])  // reorder freely

Scenario: an Order behaves differently depending on its status — you can pay a pending order, cancel a paid one, but not cancel a shipped one. Encoding this as if (status === …) checks scattered across every method is bug-prone. The State pattern makes each state an object that defines what's allowed and where you can transition.

परिस्थिती: एक Order त्याच्या status नुसार वेगळं वागतो — तुम्ही pending order pay करू शकता, paid cancel करू शकता, पण shipped cancel करू शकत नाही. हे प्रत्येक method मध्ये if (status === …) तपासण्या म्हणून encode करणं bug-प्रवण. State pattern प्रत्येक state ला असा object करतं जो काय परवानगी आहे आणि कुठे transition करता येईल हे ठरवतो.

   Pending ──pay()──► Paid ──ship()──► Shipped ──deliver()──► Delivered
      │  cancel() → Cancelled   │ cancel() → refund+Cancelled   │ cancel()? ❌ blocked
   each state OBJECT knows: which actions are legal + where they lead.
   context.cancel() delegates to current state — no scattered status ifs.

interface OrderState { pay(o: Order): void; cancel(o: Order): void }

class Pending implements OrderState {
  pay(o){ o.setState(new Paid()) }
  cancel(o){ o.setState(new Cancelled()) }
}
class Paid implements OrderState {
  pay(o){ throw new Error('already paid') }
  cancel(o){ o.refund(); o.setState(new Cancelled()) }
}
class Shipped implements OrderState {
  pay(o){ throw new Error('already paid') }
  cancel(o){ throw new Error('cannot cancel a shipped order') }   // illegal transition
}
class Order { constructor(private state: OrderState = new Pending()){}
  setState(s: OrderState){ this.state = s }
  pay(){ this.state.pay(this) }  cancel(){ this.state.cancel(this) } }

Scenario: every data importer does the same dance — open source, read rows, parse (CSV vs JSON vs XML differs), validate, write to DB, close. The skeleton is identical; only a step or two vary. Template Method defines the skeleton in a base class and lets subclasses fill in specific steps (hook methods).

परिस्थिती: प्रत्येक data importer तेच नृत्य करतो — source उघड, rows वाच, parse (CSV vs JSON vs XML वेगळं), validate, DB मध्ये लिही, बंद कर. कणा एकसारखा; फक्त एक-दोन steps बदलतात. Template Method कणा एका base class मध्ये ठरवतं आणि subclasses ना विशिष्ट steps भरू देतं (hook methods).

   Importer.run()  (template method — fixed skeleton)
     open()          ← shared
     rows = read()   ← shared
     parse(rows)     ← ABSTRACT hook  ► CsvImporter / JsonImporter override
     validate()      ← shared
     write()         ← shared (or hook)
     close()         ← shared
   subclass changes parse(); it CANNOT reorder or skip the skeleton steps

abstract class Importer {
  run(source: string) {                         // the TEMPLATE METHOD (fixed flow)
    const raw = this.open(source)
    const rows = this.parse(raw)                 // ← the varying step (hook)
    const valid = rows.filter(r => this.validate(r))
    this.write(valid)
    this.close()
  }
  protected abstract parse(raw: string): Row[]   // subclasses fill this in
  protected open(s: string){ /* shared */ return read(s) }
  protected validate(r: Row){ return r.id != null }   // shared default (overridable)
  protected write(rows: Row[]){ /* shared */ }
  protected close(){ /* shared */ }
}
class CsvImporter  extends Importer { parse(raw){ return csv(raw) } }   // only the diff
class JsonImporter extends Importer { parse(raw){ return JSON.parse(raw) } }

Scenario: you want to loop over a collection — an array, a tree, a paginated API, a database cursor — without caring how it stores its elements. The Iterator pattern provides a uniform way to walk a collection one element at a time, hiding whether it's backed by an array, a linked list, or lazy pages.

परिस्थिती: तुम्हाला एका collection वर loop करायचं आहे — array, tree, paginated API, database cursor — त्याचे elements कसे साठवले याची पर्वा न करता. Iterator pattern collection एक-एक element ने चालायचा एकसमान मार्ग देतो, ती array, linked list, की lazy pages यांनी backed आहे हे लपवून.

   for (const x of collection) { … }
                │  works the same whether collection is:
     ┌──────────┼───────────┬───────────────┬──────────────┐
   Array     LinkedList   Tree (in-order)  DB cursor    Paginated API
   the iterator hides HOW elements are stored/fetched; caller just walks them

class Tree {
  constructor(public value: number, public children: Tree[] = []) {}
  *[Symbol.iterator](): Iterator<number> {          // implement the iterable protocol
    yield this.value
    for (const child of this.children) yield* child     // recurse lazily
  }
}
for (const v of new Tree(1, [new Tree(2), new Tree(3)])) console.log(v)  // 1,2,3

// lazy pagination — walk an API without loading every page up front
async function* pages(url: string){
  let next = url
  while (next){ const r = await fetch(next).then(x=>x.json()); yield* r.items; next = r.next }
}

Scenario: a complex form where changing the country dropdown updates the state list, toggles a tax field, and enables/disables Submit. If every widget talks directly to every other widget, you get an N×N tangle. A Mediator puts one coordinator in the middle: widgets report to it, and it orchestrates who updates whom.

परिस्थिती: एक जटिल form जिथे country dropdown बदलल्याने state-list update होते, tax field toggle होतं, आणि Submit enable/disable होतं. प्रत्येक widget प्रत्येक इतर widget शी थेट बोलला, तर N×N गुंता होतो. एक Mediator मध्ये एक coordinator ठेवतो: widgets त्याला कळवतात, आणि तो कोण कोणाला update करावं ते orchestrate करतो.

  ❌ every widget ↔ every widget:        ✅ mediator hub:
     Country ── State                     Country ─┐
        │  ╲  ╱  │                        State  ──┤
     Tax ─── Submit  (tangled mesh)       Tax    ──┼─► Mediator (coordination rules)
                                          Submit ──┘
   N² connections → N connections to one coordinator; rules centralized

class FormMediator {
  constructor(private country: Select, private state: Select,
              private tax: Field, private submit: Button) {}
  notify(sender: string, event: string) {                 // components report here
    if (sender === 'country' && event === 'change') {
      this.state.loadFor(this.country.value)              // mediator decides the ripple
      this.tax.setVisible(this.country.value === 'US')
      this.submit.setEnabled(this.country.value !== '')
    }
  }
}
// widgets call mediator.notify('country','change') — they never touch each other

Scenario: a document editor needs undo. You must snapshot the document's state before each change and restore it later — without exposing or breaking the document's encapsulation. The Memento pattern captures an object's internal state into an opaque token you can stash and later use to roll back.

परिस्थिती: एका document editor ला undo लागतं. तुम्ही प्रत्येक बदलाआधी document चं state snapshot घ्यावं आणि नंतर पुनर्संचयित करावं — document ची encapsulation न उघडता किंवा न मोडता. Memento pattern object चं internal state एका opaque token मध्ये पकडतं जो तुम्ही साठवू आणि नंतर roll back करायला वापरू शकता.

   Editor.save()   ──► Memento{ text, cursor }  ──► pushed onto undo-stack (caretaker)
   ...user edits...
   Editor.undo()   ◄── pop Memento  ◄── restore(state)
   caretaker holds snapshots but can't read/alter them — encapsulation preserved

class EditorMemento { constructor(readonly text: string, readonly cursor: number) {} }

class Editor {
  private text = ''; private cursor = 0
  type(s: string){ this.text += s; this.cursor += s.length }
  save(): EditorMemento { return new EditorMemento(this.text, this.cursor) }  // snapshot
  restore(m: EditorMemento){ this.text = m.text; this.cursor = m.cursor }     // roll back
}
class History {                                   // caretaker — holds opaque mementos
  private stack: EditorMemento[] = []
  backup(e: Editor){ this.stack.push(e.save()) }
  undo(e: Editor){ const m = this.stack.pop(); if (m) e.restore(m) }
}

Scenario: you have an AST (abstract syntax tree) of node types — NumberLit, BinaryOp, FunctionCall — and you keep needing new operations over it: evaluate, pretty-print, type-check, minify. Adding each as a method on every node type bloats the nodes. Visitor lets you add new operations without touching the node classes — each operation is a separate visitor.

परिस्थिती: तुमच्याकडे node types चं AST आहे — NumberLit, BinaryOp, FunctionCall — आणि तुम्हाला त्यावर सतत नवीन operations लागतात: evaluate, pretty-print, type-check, minify. प्रत्येक node type वर method म्हणून जोडणं nodes फुगवतं. Visitor तुम्हाला node classes ला हात न लावता नवीन operations जोडू देतं — प्रत्येक operation एक वेगळा visitor.

   AST nodes (stable):   NumberLit   BinaryOp   FunctionCall
        each has accept(v) ─► calls v.visitNumberLit(this) etc. (double dispatch)
   operations (grow often), each a visitor:
        EvalVisitor      visitNumberLit  visitBinaryOp  visitFunctionCall
        PrintVisitor     "                                             "
        TypeCheckVisitor "                                             "
   add an operation → new visitor class. node classes never change.

interface Visitor { number(n: NumberLit): any; binary(b: BinaryOp): any }
interface Node { accept(v: Visitor): any }

class NumberLit implements Node { constructor(readonly value: number){}
  accept(v: Visitor){ return v.number(this) } }             // double dispatch
class BinaryOp implements Node { constructor(readonly op: string, readonly l: Node, readonly r: Node){}
  accept(v: Visitor){ return v.binary(this) } }

class EvalVisitor implements Visitor {                       // one operation = one visitor
  number(n){ return n.value }
  binary(b){ const l=b.l.accept(this), r=b.r.accept(this); return b.op==='+'? l+r : l*r }
}
// add PrintVisitor / TypeCheckVisitor later — NumberLit/BinaryOp never change