Change Reference to Value: যেকোনো ১০ টাকার নোটই সমান

💵 পকেটে দশ টাকার নোট

ধরো সুমাইয়া তার কলেজের গেটের বাইরের দোকান থেকে ১০ টাকায় সিঙ্গারা কিনলো। দোকানদার জামাল ভাইকে একটু কুঁচকানো ১০ টাকার নোট দিলো। বিকেলে চা কিনতে গেলে জামাল ভাই খুচরো হিসেবে একটা ১০ টাকার নোট ফেরত দিলেন — সকালে দেওয়াটার থেকে আলাদা, একটু বেশি সোজা, এক কোণে কারো ফোন নম্বর লেখা।

সুমাইয়া কি অভিযোগ করবে? "ভাই, এটা আমার নোট না! আমারটায় কোণে একটু ভাঁজ ছিল!"

অবশ্যই না। ব্যাপারটা হাস্যকর। একটু ভাবো কেন হাস্যকর। পৃথিবীতে কেউ track করে না তার কাছে কোন নির্দিষ্ট ১০ টাকার নোট আছে। প্রতিটি ১০ টাকার নোটের মান ঠিক ১০ টাকা, আর যেকোনো একটি অন্যটির সাথে অবাধে বদলানো যায়। সিরিয়াল নম্বর আছে — বাংলাদেশ ব্যাংক দরকার হলে নোট track করে — কিন্তু দৈনন্দিন জীবনে সিরিয়াল নম্বরের কোনো মানে নেই। নোট সম্পর্কে যেটা গুরুত্বপূর্ণ সেটা হলো এর মান, এর পরিচয় নয়।

এবার সুমাইয়ার কলেজ ID card-এর কথা ভাবো। একদিন অফিস card গুলিয়ে ফেলে সুমাইয়াকে নাসরিনের ID দিয়ে দেয় — একই কোর্স, একই বছর। এটা কি ঠিক আছে? একদমই না। ID card একজন নির্দিষ্ট মানুষকে represent করে। সুমাইয়া নাসরিনের card দিয়ে পরীক্ষায় বসতে পারবে না, যতই "সমান" দেখতে হোক না কেন। ID card-এর পরিচয় আছে। ১০ টাকার নোটের নেই।

এই একটা পার্থক্য — নোট বনাম ID card — এটাই আজকের refactoring-এর পুরো পাঠ। আমাদের program-এ কিছু object হলো ID card: customer, student, account। ঠিক কোনটা ধরা আছে সেটা track করতে হয়। কিন্তু অনেক object হলো ১০ টাকার নোট: টাকার পরিমাণ, তারিখ, ফোন নম্বর, মানচিত্রের স্থানাঙ্ক। এগুলোর জন্য "কোনটা?" জিজ্ঞেস করাটাই অর্থহীন — শুধু "কত মান?" টাই অর্থবহ।

Change Reference to Value সেই মুহূর্তের জন্য যখন দেখো একটা ১০ টাকার নোটকে ID card-এর মতো treat করা হচ্ছে — একটা tracked instance share করা হচ্ছে, সেটা in-place পরিবর্তন করা হচ্ছে, "এটা কি একই object?" দিয়ে তুলনা করা হচ্ছে — অথচ এই concept-এর কখনোই কোনো পরিচয় ছিল না। সমাধান: এটাকে একটা ছোট, immutable value বানাও। একই contents সহ যেকোনো অন্য value-এর সমান।

🧠 Change Reference to Value কী?

Change Reference to Value হলো Martin Fowler-এর Refactoring বই থেকে একটা refactoring। পরিস্থিতিটা এরকম: একটা object-কে reference হিসেবে manage করা হচ্ছে — registry বা factory দিয়ে তৈরি করা হচ্ছে, holder-দের মধ্যে share করা হচ্ছে, in-place পরিবর্তন করা হচ্ছে, identity দিয়ে তুলনা করা হচ্ছে — অথচ এটা যে concept represent করে তার কোনো আসল পরিচয় নেই। যেমন একটা currency, একটা date range, একটা টাকার পরিমাণ। "THE পাঁচশো টাকা" বলে কিছু নেই। যেকোনো ৫০০ টাকা অন্য যেকোনো ৫০০ টাকার সমান।

এমন একটা concept-কে reference হিসেবে treat করলে অপ্রয়োজনীয় ঝামেলা বেড়ে যায়: instance lookup করার জন্য registry, সতর্ক lifecycle management, আর — সবচেয়ে খারাপ হলো — aliasing-এর বিপদ। একজন holder shared object পরিবর্তন করে, আর অন্য সব holder-এর data চুপচাপ বদলে যায়।

এই কাজের তিনটা অংশ:

1. Object-কে immutable করো। Setter সরাও। আগে যেসব method object পরিবর্তন করত সেগুলো এখন নতুন object return করবে — নোটে লেখার বদলে নোট বদলানোর মতো।
2. এটাকে value equality দাও। সমান contents সহ দুটো object সমান, শেষ কথা। equals/== আর hash code override করো যাতে সেগুলো একমত হয়।
3. Sharing machinery মুছে দাও। Registry, factory cache, lookup — সব গেল। যে কেউ যেখানে খুশি value তৈরি করতে পারবে, কারণ copy নিরীহ।

Refactoring-এর পর, object-টা Martin Fowler-এর অর্থে একটা সত্যিকারের value object হয়: ছোট, immutable, contents দিয়ে তুলনীয়। তার প্রিয় উদাহরণ হলো Money — একটা পরিমাণ আর একটা currency। Value Object bliki-তে তার rule of thumb পরিষ্কার: value গুলো equality method override করে; entity গুলো সাধারণত করে না। Equality আক্ষরিক অর্থে সেই fingerprint যা তোমাকে বলে কোন ধরনের object তুমি দেখছ।

আমাদের একমাত্র guiding প্রশ্নটা মনে করো, Change Value to Reference থেকেও একই:

"এটা কি THE একই জিনিস, নাকি শুধু AN সমান জিনিস?"

যদি "AN সমান জিনিস" যথেষ্ট হয় — যেকোনো সমান নোটই চলবে — তাহলে concept-টা একটা value। এই refactoring code-কে সেই সত্যের সাথে মেলায়।

একটু deep dive করি: এই refactoring যে bug মারে তাকে বলে aliasing। দুটো নাম (variable, field) একটা mutable object-এর সাথে বাঁধা, তাই এক নামের মাধ্যমে write করলে অন্য নামের মাধ্যমে সেটা দেখা যায়। Aliasing সবসময় ভুল নয় — entity গুলো ঠিক এটাই চায়। কিন্তু অনিচ্ছাকৃত aliasing সবচেয়ে কঠিন trace করার মতো bug, কারণ দূষণকারী write হয় অনেক দূরে এমন code-এ যেটা "স্পষ্টতই" অন্য কিছু touch করছে। Functional programming language গুলো সবকিছু immutable করে পুরো সমস্যাটা সমাধান করে। Value object গুলো সেই সমাধান surgically import করে — শুধু যেখানে identity অর্থহীন সেখানে immutability প্রয়োগ করে। একটা immutable object এছাড়াও automatically thread-safe: কোনো write নেই মানে কোনো data race নেই, কোনো lock নেই।

🔔 কখন এটা দরকার?

এই refactoring-এর কথা ভাবো যখন দেখবে:

1. Aliasing bug ("spooky action at a distance")। তুমি এক order-এর discount পরিবর্তন করলে সম্পূর্ণ ভিন্ন একটা order-এর total পরিবর্তন হয়ে যাচ্ছে — কারণ দুটো গোপনে একটা mutable object share করছিল। এটাই সবচেয়ে বড় সংকেত।
2. Identity-free কিছুর জন্য registry। এমন একটা cache যেটা Currency বা Money instance intern করে "যাতে == কাজ করে" — সেটা ভুল model-কে support করছে। Value equality এই প্রয়োজনীয়তা দূর করে।
3. Identity ছাড়া concept-এ identity comparison। Code যেটা amount বা date-এর জন্য a === b বা ReferenceEquals(a, b) জিজ্ঞেস করছে, আর যখনই একটা সমান-কিন্তু-আলাদা instance আসে তখন ভেঙে পড়ছে — যেমন JSON deserialization-এর পর।
4. Distributed বা parallel সমস্যা। Fowler উল্লেখ করেন reference গুলো process জুড়ে বিশেষভাবে awkward। নেটওয়ার্কের উপর দিয়ে pointer share করা যায় না। Value গুলো সুখে travel করে — serialize করো, পাঠাও, recreate করো, তবুও সমান।
5. Collection গণ্ডগোল করছে। তুমি Money-কে map key বা set-এ চাও, কিন্তু value-based equals/hashCode ছাড়া collection সমান amount গুলোকে ভিন্ন entry হিসেবে treat করে।

এই refactoring Primitive Obsession যে যাত্রা শুরু করে তাও সম্পূর্ণ করে। প্রথমে তুমি একটা raw number-কে Money class-এ wrap করো (Replace Data Value with Object), তারপর এই refactoring সেই class-কে একটা সত্যিকারের value বানায় — immutable, content-equal, freely copyable। একইভাবে, যখন Data Clumps একটা Address বা DateRange-এ bundle হয়, সেই bundle গুলো প্রায় সবসময় value semantics deserve করে।

কখন ব্যবহার করবে না: যখন object-টার সত্যিই identity আর shared changing state আছে — একজন customer, একটা account, একটা live order। এগুলোকে value বানালে update গুলো propagate হওয়া বন্ধ হয়ে যাবে। Concept নির্ধারণ করে, fashion নয়।

সংকেত গুলোর একটা quick triage table:

👀 এক নজরে আগে আর পরে

দেখো TypeScript-এ এই রোগটা — একটা shared, mutable Money cache দিয়ে বিতরণ করা হচ্ছে:

// BEFORE — Money treated like an ID card
class Money {
  constructor(
    public amount: number,
    public currency: string,
  ) {}
 
  addTo(delta: number): void {
    this.amount += delta; // mutates in place!
  }
}
 
// A registry "interning" money so identity comparison works:
const cache = new Map<string, Money>();
function money(amount: number, currency: string): Money {
  const key = `${amount}-${currency}`;
  if (!cache.has(key)) cache.set(key, new Money(amount, currency));
  return cache.get(key)!;
}
 
const samosaPrice = money(10, "INR");
const chaiPrice = money(10, "INR"); // SAME shared object as samosaPrice
 
samosaPrice.addTo(5); // samosa got costlier...
console.log(chaiPrice.amount); // 15 — chai price changed too! Spooky!
console.log(samosaPrice === chaiPrice); // true, but only by accident of the cache

জামাল ভাই ভয় পেয়ে যেতেন। সিঙ্গারার দাম বাড়ানোতে কোনো কারণে চায়ের দামও বাড়লো, কারণ দুটো দামই গোপনে একই নোট ছিল। এরপর — Money একটা সৎ ১০ টাকার নোট হয়:

// AFTER — Money as a value: immutable, content-equal, freely created
class Money {
  constructor(
    public readonly amount: number,
    public readonly currency: string,
  ) {
    Object.freeze(this); // belt and braces: runtime immutability
  }
 
  plus(delta: number): Money {
    return new Money(this.amount + delta, this.currency); // a NEW note
  }
 
  equals(other: Money): boolean {
    return this.amount === other.amount && this.currency === other.currency;
  }
}
 
const samosaPrice = new Money(10, "INR");
const chaiPrice = new Money(10, "INR"); // separate object, and that is FINE
 
const newSamosaPrice = samosaPrice.plus(5);
 
console.log(chaiPrice.amount); // 10 — untouched, no spooky action
console.log(samosaPrice.equals(chaiPrice)); // true — AN equal thing
console.log(samosaPrice === chaiPrice); // false — and nobody cares

Cache মুছে গেল। Mutation চলে গেল — টাকা "পরিবর্তন" মানে নতুন টাকা বানানো। আর equality এখন সেই একমাত্র প্রশ্নই করে যেটা টাকার জন্য কখনো অর্থবহ ছিল: একই পরিমাণ, একই currency?

🪜 ধাপে ধাপে, নিরাপদ উপায়ে

1. নিশ্চিত করো concept-টার কোনো identity নেই। তোমার team-এর সাথে টাকার নোটের প্রশ্নটা করো: যদি দুটো instance-এর সমান field থাকে, এমন কোনো পরিস্থিতি আছে কি যেখানে program-কে সেগুলোকে আলাদা করতে হবে? যদি হ্যাঁ — থামো, এটা entity। যদি না — এগিয়ে যাও।

2. Object-কে immutable করো, একটা দরজা একবারে। Setter সরাও বা private করো। প্রতিটা mutating method-এর জন্য, একটা non-mutating twin যোগ করো যেটা নতুন instance return করে, caller গুলোকে twin-এ migrate করো, তারপর mutator মুছে দাও:

class Money {
  // Step 2 (intermediate): both methods exist while callers migrate
  addTo(delta: number): void {
    this.amount += delta; // old, dying
  }
  plus(delta: number): Money {
    return new Money(this.amount + delta, this.currency); // new, growing
  }
}

3. Field গুলো readonly চিহ্নিত করো একবার কোনো mutator না থাকলে। Compiler এখন তোমার জন্য immutability prove করে আর যেকোনো straggler-কে error হিসেবে দেখায়।

4. Value equality আর matching hash implement করো। প্রতিটা defining field দুটোতেই অংশ নেয়। TypeScript-এ এটা হলো equals method (আর toKey() string যদি map key দরকার হয়, কারণ JS map গুলো object identity দিয়ে তুলনা করে)। C#, Java, Kotlin, আর Python-এ language feature ব্যবহার করো — record, record class, data class, @dataclass(frozen=True) — compiler সঠিক, সবসময়-synchronized equality আর hashing লেখে।

5. Registry ভেঙে ফেলো। Constructor public করো, cache আর factory lookup মুছে দাও, caller-দের স্বাধীনভাবে new Money(10, "INR") লিখতে দাও। Diff দেখো কীভাবে ছোট হয় — মুছে যাওয়া machinery এই refactoring-এর দৃশ্যমান পুরস্কার।

6. Identity check গুলোকে value check-এ বদলাও। এই type-এ ===, ReferenceEquals, is (Python) খোঁজো আর প্রতিটিকে equals/==-এ convert করো। তারপর পুরো test suite চালাও। বিশেষ মনোযোগ দিয়ে দেখো এমন code যেটা shared mutation propagate হওয়ার উপর নির্ভর করত — ওই code-এর একটা real entity দরকার, বা একটা explicit update path।

আরেকটু গভীরে যাই: equals-hash contract-এর একটা দ্বিতীয়, সূক্ষ্ম clause আছে। Dictionary key হিসেবে ব্যবহৃত object-এর hash dictionary-তে থাকাকালীন কখনো পরিবর্তন হওয়া উচিত না। Hash container গুলো প্রতিটা entry insertion-এর সময় তার hash দিয়ে বেছে নেওয়া bucket-এ store করে। Hash-এ feed করে এমন field পরিবর্তন করলে lookup এখন ভিন্ন bucket compute করে — entry এখনো আছে কিন্তু আর কখনো খুঁজে পাওয়া যাবে না। এ কারণেই "mutable value object" একটা contradiction। Value equality field-based hashing দাবি করে, আর field-based hashing দাবি করে field গুলো কখনো পরিবর্তন না হোক। Immutability এখানে stylistic preference নয় — এটাই value semantics-কে mathematically coherent করে।

🏫 একটা বড় বাস্তব উদাহরণ

ধরো একটা travel-booking app-এ hotel stay-এর জন্য একটা DateRange model করা হয়েছে। কেউ বছর আগে এটাকে shared, mutable reference বানিয়েছিল "memory বাঁচাতে," আর তারপর থেকে bug কামড়াচ্ছে:

// BEFORE — a shared, mutable DateRange
class DateRange {
  constructor(
    public checkIn: string, // "2026-07-01"
    public checkOut: string, // "2026-07-05"
  ) {}
 
  extendByDays(days: number): void {
    const out = new Date(this.checkOut);
    out.setDate(out.getDate() + days);
    this.checkOut = out.toISOString().slice(0, 10); // mutation!
  }
}
 
class Booking {
  constructor(
    public readonly hotel: string,
    public stay: DateRange,
  ) {}
}
 
// The bug: a "copy" that is not a copy
const stay = new DateRange("2026-07-01", "2026-07-05");
const goa = new Booking("Sea Breeze, Goa", stay);
const munnar = new Booking("Hill View, Munnar", stay); // same object reused!
 
goa.stay.extendByDays(2); // guest extends Goa stay...
console.log(munnar.stay.checkOut); // 2026-07-07 — Munnar booking changed too!

একজন guest Goa-তে stay বাড়ালো, আর Munnar-এর booking চুপচাপ দুই দিন বেড়ে গেল। Munnar-এর hotel কেউ ঘুমায়নি এমন রাতের বিল করছে। DateRange-কে value বানানোর পর:

// AFTER — DateRange as an immutable value
class DateRange {
  constructor(
    public readonly checkIn: string,
    public readonly checkOut: string,
  ) {
    if (checkOut <= checkIn) {
      throw new Error("Check-out must be after check-in");
    }
    Object.freeze(this);
  }
 
  extendByDays(days: number): DateRange {
    const out = new Date(this.checkOut);
    out.setDate(out.getDate() + days);
    return new DateRange(this.checkIn, out.toISOString().slice(0, 10));
  }
 
  nights(): number {
    const ms = +new Date(this.checkOut) - +new Date(this.checkIn);
    return Math.round(ms / 86_400_000);
  }
 
  equals(other: DateRange): boolean {
    return this.checkIn === other.checkIn && this.checkOut === other.checkOut;
  }
 
  overlaps(other: DateRange): boolean {
    return this.checkIn < other.checkOut && other.checkIn < this.checkOut;
  }
}
 
class Booking {
  constructor(
    public readonly hotel: string,
    public readonly stay: DateRange,
  ) {}
 
  extendStay(days: number): Booking {
    return new Booking(this.hotel, this.stay.extendByDays(days));
  }
}
 
const stay = new DateRange("2026-07-01", "2026-07-05");
const goa = new Booking("Sea Breeze, Goa", stay);
const munnar = new Booking("Hill View, Munnar", stay); // sharing is now HARMLESS
 
const extendedGoa = goa.extendStay(2);
console.log(extendedGoa.stay.checkOut); // 2026-07-07
console.log(munnar.stay.checkOut); // 2026-07-05 — perfectly safe

ভালো জিনিসগুলোর chain reaction লক্ষ্য করো। দুটো booking-এর মধ্যে একই DateRange share করা আর bug নয়। Immutable value গুলো এক মিলিয়ন holder দ্বারা কোনো risk ছাড়াই share হতে পারে। মানে "memory বাঁচানোর" original লক্ষ্যটা mutable cache-এর চেয়ে value design দ্বারা ভালোভাবে অর্জিত হয় — যে cache bug সৃষ্টি করেছিল। Validation constructor-এ চলে গেল, তাই উল্টো range কখনো exist করতে পারবে না। আর type-টা সত্যিকারের useful behaviour আকর্ষণ করলো (nights, overlaps) কারণ এটা এখন একটা real domain concept।

💜 C#-এ একই refactoring

এখানেই C# records সবচেয়ে উজ্জ্বল হয় — একটা record হলো language-এ built-in একটা value object kit। init-only properties দিয়ে immutability, value equality, matching hash code, ToString, আর with expression দিয়ে non-destructive mutation — সব compiler-generated:

public sealed record DateRange
{
    public DateOnly CheckIn { get; }
    public DateOnly CheckOut { get; }
 
    public DateRange(DateOnly checkIn, DateOnly checkOut)
    {
        if (checkOut <= checkIn)
            throw new ArgumentException("Check-out must be after check-in");
        CheckIn = checkIn;
        CheckOut = checkOut;
    }
 
    public int Nights => CheckOut.DayNumber - CheckIn.DayNumber;
 
    public DateRange ExtendByDays(int days) =>
        new(CheckIn, CheckOut.AddDays(days));
 
    public bool Overlaps(DateRange other) =>
        CheckIn < other.CheckOut && other.CheckIn < CheckOut;
}
 
var a = new DateRange(new(2026, 7, 1), new(2026, 7, 5));
var b = new DateRange(new(2026, 7, 1), new(2026, 7, 5));
 
Console.WriteLine(a == b);                  // True  — value equality, FREE
Console.WriteLine(ReferenceEquals(a, b));   // False — and irrelevant

আর with-expression update সহ positional record হিসেবে Money:

public readonly record struct Money(decimal Amount, string Currency)
{
    public Money Plus(decimal delta) => this with { Amount = Amount + delta };
 
    public override string ToString() => $"{Currency} {Amount:F2}";
}
 
var samosa = new Money(10m, "INR");
var costlier = samosa with { Amount = 15m };  // NEW value, original untouched
 
Console.WriteLine(samosa);    // INR 10.00
Console.WriteLine(costlier);  // INR 15.00
Console.WriteLine(samosa == new Money(10m, "INR")); // True

এটা কেন refactoring-এর সাথে নিখুঁতভাবে মেলে:

• record বনাম class হলো একটা keyword-এ value/reference split। একটা plain class reference দিয়ে তুলনা করে (ID card); একটা record contents দিয়ে তুলনা করে (১০ টাকার নোট)। Keyword পরিবর্তন করাটাই আক্ষরিক অর্থে Change Reference to Value।
• readonly record struct এমনকি heap allocation-ও সরিয়ে দেয় — value inline থাকে, hot path-এর জন্য আদর্শ।
• with expression হলো idiomatic "নোট বদলানোর" operation: সবকিছু copy করো, একটা field পরিবর্তন করো, original অস্পর্শিত।
• .NET-এর জন্য Microsoft-এর DDD guidance value object-এর জন্য record recommend করে, EF Core-সহ owned types বা value converter দিয়ে mapping করে — তাই database plain column store করে আর code পুরো value semantics উপভোগ করে।

Python frozen dataclass-এর মাধ্যমে একই kit দেয় — এক decorator-এ immutability, content equality, আর hashing:

from dataclasses import dataclass, replace
from datetime import date
 
@dataclass(frozen=True)
class DateRange:
    check_in: date
    check_out: date
 
    def __post_init__(self) -> None:
        if self.check_out <= self.check_in:
            raise ValueError("Check-out must be after check-in")
 
    def extend_by_days(self, days: int) -> "DateRange":
        from datetime import timedelta
        return replace(self, check_out=self.check_out + timedelta(days=days))
 
    @property
    def nights(self) -> int:
        return (self.check_out - self.check_in).days
 
 
a = DateRange(date(2026, 7, 1), date(2026, 7, 5))
b = DateRange(date(2026, 7, 1), date(2026, 7, 5))
assert a == b          # content equality, generated
assert a is not b      # different objects — and nobody cares
assert hash(a) == hash(b)  # frozen=True makes hashing safe

একটু লক্ষ্য করো: frozen=True কী করে dataclass-টাকে default-এ hashable করে তোলে। eq=True সহ একটা mutable dataclass-এ __hash__ None-এ set হয় — Python তোমাকে আগে বলা broken-bucket bug থেকে রক্ষা করছে, content-equal mutable object-কে set-এ ঢুকতে দিতে অস্বীকার করছে। Language designer গুলো decorator-এর default-এ সরাসরি equals-hash-immutability triangle encode করেছে। যখন একটা language mutable object hash করতে বাধা দেয়, সেটা pedantic হচ্ছে না; সেটা contract মনে করিয়ে দিচ্ছে।

🛠️ IDE support

⚖️ সুবিধা আর ঝুঁকি — আর দোলনা

প্রথমে দোলনা — কারণ এই refactoring আর Change Value to Reference সঠিক বিপরীত। একটা concept-কে shared identity-র দিকে ঠেলে; অন্যটা সেটাকে free-floating value-এ টেনে আনে। নির্ধারণকারী প্রশ্ন কখনো বদলায় না: "এটা কি THE একই জিনিস, নাকি শুধু AN সমান জিনিস?"

যদি stale copy-র বিরুদ্ধে লড়তে হয়, দোলনাকে reference-এর দিকে কাত করো। যদি aliasing আর registry-র বিরুদ্ধে লড়তে হয়, value-এর দিকে কাত করো। একই সময়ে দুটোর বিরুদ্ধে লড়া সাধারণত মানে একটা concept গোপনে দুটো — একটা entity যেটার ভেতরে value object আছে, যেমন একটা Customer (entity) যেটার মধ্যে একটা Address (value) আছে।

এখন এই direction-এর ledger:

🧹 এটা কোন smell গুলো ঠিক করে?

📦 Quick revision box

+--------------------------------------------------------------+
|            CHANGE REFERENCE TO VALUE — REVISION              |
+--------------------------------------------------------------+
| Idea     : A shared, mutable, identity-tracked object that   |
|            has NO real identity becomes an immutable value.  |
| Key Q    : "Is it THE same thing, or just AN equal thing?"   |
|            AN equal thing -> value (this refactoring)        |
|            THE same thing -> reference (see the inverse)     |
| Mnemonic : Rs.10 note = value; school ID card = entity.      |
| Steps    : 1. Confirm: no identity, equal fields = equal     |
|            2. Remove mutators; add return-new twins          |
|            3. Mark all fields readonly/init                  |
|            4. Value equality + MATCHING hash (use records!)  |
|            5. Delete the registry; constructor goes public   |
|            6. Replace === / ReferenceEquals with equals      |
| Watch out: equal-but-different-hash kills dictionaries;      |
|            code that depended on shared mutation.            |
| C# bonus : record / readonly record struct = the whole       |
|            refactoring in one keyword.                       |
| Inverse  : Change Value to Reference (the seesaw's far end)  |
+--------------------------------------------------------------+

✍️ অনুশীলন করো

ধরো একটা ride-sharing app একটা mutable Location object সবখানে share করছে। Riders রিপোর্ট করছে যে তাদের saved "Home" location রহস্যজনকভাবে সরে যাচ্ছে:

class Location {
  constructor(
    public lat: number,
    public lng: number,
    public label: string,
  ) {}
 
  moveTo(lat: number, lng: number): void {
    this.lat = lat;
    this.lng = lng;
  }
}
 
const locationCache = new Map<string, Location>();
function getLocation(label: string, lat: number, lng: number): Location {
  if (!locationCache.has(label)) {
    locationCache.set(label, new Location(lat, lng, label));
  }
  return locationCache.get(label)!;
}
 
// The bug in the wild:
const home = getLocation("Home", 17.385, 78.4867);
const tripStart = getLocation("Home", 17.385, 78.4867); // same shared object
tripStart.moveTo(17.4474, 78.3762); // driver adjusts pickup point...
console.log(home.lat, home.lng); // Home has MOVED. Rider is not amused.

তোমার কাজ:

1. টাকার নোটের প্রশ্নটা দিয়ে সিদ্ধান্ত নাও: একটা Location (স্থানাঙ্কের একটা জোড়া আর একটা label) কি identity আছে, নাকি এটা value? তোমার এক-লাইনের justification একটা comment হিসেবে লেখো।
2. Location immutable করো: readonly field, constructor validation (latitude -90 আর 90-এর মধ্যে, longitude -180 আর 180-এর মধ্যে), আর একটা withCoordinates(lat, lng) method যেটা নতুন Location return করে।
3. তিনটা field-ই compare করে equals(other) যোগ করো, আর map-এ ব্যবহারের জন্য toKey() string।
4. locationCache আর getLocation সম্পূর্ণ মুছে দাও। Bug scenario ঠিক করো আর একটা test দিয়ে prove করো যে pickup point adjust করলে "Home" অস্পর্শিত থাকে।
5. C#-এ Bonus: Location-কে readonly record struct হিসেবে লেখো with-expression উদাহরণসহ, আর দেখাও যে দুটো সমান location == true compare করে।
6. Python-এ Bonus: Location-কে @dataclass(frozen=True) হিসেবে লেখো আর confirm করো যে এটা একটা set-এর ভেতরে নিরাপদে থাকতে পারে।
7. চিন্তার প্রশ্ন: app-টাতে একটা Driver object-ও আছে। Driver-কেও কি একই treatment দেওয়া উচিত? Seesaw দিয়ে উত্তর দাও — আর যদি না হয়, তুমি পরিবর্তে কোন refactoring check করবে সেটার নাম বলো।

তোমার fixed test যদি দেখায় "Home" দাঁড়িয়ে আছে আর pickup point সরছে, তাহলে তুমি জামাল ভাইয়ের জ্ঞান বুঝেছ: নোট বদলাও, কখনো নোটে লিখো না।