Scenario: you need a service that fetches a user, caches the result, and retries on failure. Inheritance tempts you into class CachedRetryingUserService extends UserService — and the combinations explode (cached? retrying? logged?). Composition instead assembles behaviors from small parts: a service that has a cache and has a retry policy.

परिस्थिती: तुम्हाला एक service हवी जी user आणते, result cache करते, आणि अपयशी झाल्यास retry करते. Inheritance तुम्हाला class CachedRetryingUserService extends UserService कडे खेचतं — आणि संयोग स्फोटासारखे वाढतात (cached? retrying? logged?). Composition त्याऐवजी छोट्या भागांतून behavior जुळवतं: अशी service जिच्याकडे cache आहे आणि retry policy आहे.

  ❌ inheritance explosion:            ✅ composition:
     UserService                        UserService(
     CachedUserService                    fetch = HttpFetcher,
     RetryingUserService                   cache = RedisCache,
     CachedRetryingUserService             retry = RetryPolicy(3))
     LoggedCachedRetryingUserService…    mix behaviors at runtime, no new classes

// ✅ has-a: the service is GIVEN a cache and a retry policy
class UserService {
  constructor(
    private fetch: Fetcher,       // has-a fetcher (swap HTTP / gRPC / fake)
    private cache: Cache,         // has-a cache
    private retry: RetryPolicy,   // has-a retry policy
  ) {}
  async get(id: string): Promise<User> {
    return this.cache.getOrSet(id, () =>
      this.retry.run(() => this.fetch.user(id)))
  }
}
// caching + retry are now reusable parts, mixable with ANY service — no subclasses

class CachedUserService extends UserService {}
class RetryingUserService extends UserService {}
class CachedRetryingUserService extends ...  // explosion

class UserService {
  constructor(private fetch: Fetcher, private cache: Cache,
              private retry: RetryPolicy){}   // mix at runtime
}

Scenario: your report generator needs "somewhere to write bytes." It shouldn't care whether that's a file, an S3 upload, or an in-memory buffer for tests. An interface (Writer) names that capability, and anything that satisfies it — by declaration or by shape — can be passed in.

परिस्थिती: तुमच्या report generator ला 'bytes लिहायला कुठेतरी' हवं. ते file आहे, S3 upload आहे, की testing साठी in-memory buffer आहे याची त्याला काळजी नसावी. एक interface (Writer) ती क्षमता नावाने ठेवतं, आणि ती पूर्ण करणारं काहीही — घोषणेने किंवा आकाराने — पास करता येतं.

   report.writeTo(w: Writer)      Writer = { write(bytes): void }
                                       ▲          ▲          ▲
                                  FileWriter  S3Writer  BufferWriter (tests)
   these share NO base class — only a shape. structural typing (Go/TS) &
   duck typing (Python/Ruby) accept any of them.

interface Writer { write(chunk: Uint8Array): void }     // TS: structural

function writeReport(rows: Row[], out: Writer) {         // depends on capability
  for (const r of rows) out.write(encode(r))
}
// all satisfy Writer by SHAPE — no shared base class:
writeReport(rows, fileWriter)     // a file
writeReport(rows, s3Writer)       // an S3 multipart upload
writeReport(rows, bufferWriter)   // in-memory, for a unit test

interface Repo {                    // kitchen-sink
  find(); save(); delete();
  bulkImport(); reindex(); vacuum(); migrate()
}
class Report { constructor(private r: Repo){} } // needs only find()

interface Reader { find(id): User | null }
class Report { constructor(private users: Reader){} } // 1 method

Scenario: two users named "Alex Kim" are different people even with identical data — a User has identity (an id). But two Money(10, 'USD') are the same — $10 is $10; it has no identity, just value. Modeling these two kinds differently prevents a huge class of bugs.

परिस्थिती: 'Alex Kim' नावाचे दोन users वेगळे लोक आहेत, data सारखा असला तरी — एका User ला identity (id) असते. पण दोन Money(10, 'USD') एकच आहेत — $10 म्हणजे $10; त्याला identity नाही, फक्त value. या दोन प्रकारांना वेगळं मॉडेल करणं मोठ्या bug-वर्गाला टाळतं.

   ENTITY (compare by id):          VALUE OBJECT (compare by value):
   User#42 ≠ User#43                 Money(10,USD) == Money(10,USD)
   (even if same name/email)         (interchangeable; no identity)
   mutable, tracked over time        immutable, validated on creation
   examples: User, Order, Account    examples: Money, Email, Color, DateRange

class Money {                                  // VALUE OBJECT
  private constructor(readonly cents: number, readonly currency: string) {}
  static of(amount: number, currency: string): Money {
    if (!Number.isInteger(amount * 100)) throw new Error('sub-cent amount')
    return new Money(Math.round(amount * 100), currency)   // validate on creation
  }
  add(o: Money): Money {
    if (o.currency !== this.currency) throw new Error('currency mismatch')
    return new Money(this.cents + o.cents, this.currency)  // returns a NEW Money
  }
  equals(o: Money){ return this.cents === o.cents && this.currency === o.currency }
}
// Money(10,USD).equals(Money(10,USD)) === true  — value equality, not reference

// money as a raw float: validated nowhere, rounded wrong
let price = 19.99
total += price * 1.2   // 23.987999999999996

class Money {
  private constructor(readonly cents:number, readonly ccy:string){}
  static of(a:number,c:string){ return new Money(Math.round(a*100),c) }
  add(o:Money){ /* same-currency check, integer cents */ }
}

Scenario: you pass a Config object into ten components; one of them mutates a field, and now the other nine see a value they never set — a heisenbug you'll chase for a day. Immutable objects can't be changed after creation, so "who mutated this?" stops being a question.

परिस्थिती: तुम्ही एक Config object दहा components मध्ये पास करता; त्यातलं एक field mutate करतं, आणि आता बाकीचे नऊ तुम्ही कधीच न set केलेलं value पाहतात — दिवसभर शोधावा लागणारा heisenbug. Immutable objects तयार झाल्यावर बदलता येत नाहीत, त्यामुळे 'हे कुणी mutate केलं?' हा प्रश्नच उरत नाही.

   ❌ shared mutable:                 ✅ immutable:
   cfg.timeout = 5   (component A)     cfg2 = cfg.with({ timeout: 5 })
        │  now B, C, D see 5               │  cfg is UNCHANGED; A uses cfg2
   spooky action at a distance         no shared-state surprises, thread-safe

class Config {
  constructor(readonly timeout: number, readonly retries: number) {}
  with(patch: Partial<Config>): Config {                 // returns a NEW Config
    return new Config(patch.timeout ?? this.timeout,
                      patch.retries ?? this.retries)
  }
}
const base = new Config(30, 3)
const fast = base.with({ timeout: 5 })   // base is untouched; fast is separate
// safe to pass `base` to ten components — none can mutate what another sees

function applyDiscount(cart){ cart.total *= 0.9; return cart } // mutates!
render(cart)   // the cart on screen just changed too

function withDiscount(cart){ return { ...cart, total: cart.total*0.9 } }
const discounted = withDiscount(cart)  // original cart untouched

Scenario: you change how the PricingService rounds cents, and suddenly the invoice PDF, the emailer, and three tests break. That's high coupling — too many things depend on one thing's details. Meanwhile a "UserService" that also sends email, resizes avatars, and talks to Stripe has low cohesion — it does unrelated jobs. These two dials predict how much a change hurts.

परिस्थिती: तुम्ही PricingService cents कशी round करते ते बदलता, आणि अचानक invoice PDF, emailer, आणि तीन tests मोडतात. ते उच्च coupling — खूप गोष्टी एकाच्या तपशीलांवर अवलंबून. दरम्यान email पाठवणारी, avatars resize करणारी, आणि Stripe शी बोलणारी 'UserService' कमी cohesion — ती असंबंधित कामं करते. या दोन कळा बदल किती त्रासदायक ठरेल ते सांगतात.

              HIGH cohesion (focused)      LOW cohesion (grab-bag)
  LOW    │  ✅ the goal:                 │  parts don't belong together
  coupling│    small, focused, isolated  │  but at least they're independent
  ────────┼─────────────────────────────┼──────────────────────────────
  HIGH   │  focused but entangled;      │  ❌ the nightmare: a "God object"
  coupling│    a change here ripples      │  that does everything and everyone
         │                              │  depends on (Big Ball of Mud)

// ❌ high coupling: Checkout knows the concrete PricingService + its rounding
class Checkout { constructor(private pricing: PricingService) {} }

// ✅ lower coupling: Checkout depends on a tiny interface it actually needs
interface Priced { totalFor(order: Order): Money }
class Checkout { constructor(private pricing: Priced) {} }
// now PricingService can change its internals freely; Checkout only knows totalFor
// ✅ higher cohesion: move avatar-resize + email OUT of "UserService" (topic 13)

class UserService {   // five unrelated jobs
  register(){}  hashPassword(){}  sendEmail(){}
  resizeAvatar(){}  writeAuditLog(){}
}  // edited by 5 teams; a change anywhere risks everything

class Registration {   // one job: orchestrate signup
  constructor(private users, private hasher,
              private mailer, private audit){}
}

Scenario: you write order.getCustomer().getAddress().getCountry().getCode(). It works — until Address changes shape, and now this "train wreck" breaks in every place you reached through. The Law of Demeter says: talk only to your immediate collaborators, not to their internals.

परिस्थिती: तुम्ही order.getCustomer().getAddress().getCountry().getCode() लिहिता. ते चालतं — जोपर्यंत Address चा आकार बदलत नाही, आणि मग हा 'train wreck' तुम्ही आरपार पोहोचलेल्या प्रत्येक ठिकाणी मोडतो. Law of Demeter म्हणतं: फक्त तुमच्या थेट collaborators शी बोला, त्यांच्या internals शी नाही.

  ❌ a.getB().getC().getD().value    ← knows the shape of B, C, and D
       breaks if ANY of B/C/D changes structure

  ✅ a.value()                        ← 'a' fetches it internally
       you depend only on 'a' — B/C/D can be refactored freely

// ❌ Demeter violation — Checkout knows Customer→Address→Country shape
const code = order.getCustomer().getAddress().getCountry().getCode()

// ✅ give Order the responsibility; callers stay ignorant of the chain
class Order {
  shippingCountry(): string {          // Order talks to ITS friend, Customer
    return this.customer.shippingCountryCode()
  }
}
const code = order.shippingCountry()   // Checkout depends only on Order
// now Customer/Address/Country can be refactored without touching Checkout

const code = order.getCustomer()
                  .getAddress().getCountry().getCode()
// breaks if Customer, Address, OR Country changes shape

class Order { shippingCountry(){ return this.customer.shippingCountryCode() } }
const code = order.shippingCountry()   // depend only on Order

Scenario: you write if (account.getBalance() >= amount) account.setBalance(account.getBalance() - amount). You asked for the balance, made the decision outside, and wrote it back — the account's own rule (no overdraft) now lives in the caller, and it'll be duplicated (and violated) elsewhere. Tell the account: account.withdraw(amount).

परिस्थिती: तुम्ही if (account.getBalance() >= amount) account.setBalance(...) लिहिता. तुम्ही balance विचारलं, निर्णय बाहेर घेतला, आणि परत लिहिला — account चा स्वतःचा नियम (no overdraft) आता caller मध्ये राहतो, आणि तो इतरत्र नक्कल होईल (आणि मोडेल). account ला सांगा: account.withdraw(amount).

  ❌ ASK:                              ✅ TELL:
  if (acct.getBalance() >= amt)         acct.withdraw(amt)
     acct.setBalance(bal - amt)              │  overdraft rule lives HERE, once
  else throw ...                             │  every caller gets it for free
  (rule copied into every caller)       throws InsufficientFunds internally

// ❌ ask: caller pulls state, decides, writes back — rule leaks + duplicates
if (account.getBalance() >= amount) {
  account.setBalance(account.getBalance() - amount)
} else { throw new Error('insufficient funds') }

// ✅ tell: the account owns the decision and its invariant
class Account {
  #balance: Money
  withdraw(amount: Money) {
    if (this.#balance.lessThan(amount)) throw new InsufficientFunds()
    this.#balance = this.#balance.subtract(amount)     // rule enforced HERE
  }
}
account.withdraw(amount)   // every caller is safe; no overdraft logic to copy

if(account.getBalance() >= amount)
  account.setBalance(account.getBalance() - amount)
else throw Error('insufficient')  // rule copied into every caller

account.withdraw(amount)   // the rule lives inside Account, once
// throws InsufficientFunds internally