Interface আর contract — design by contract, error handling আর immutability

১ · Interface মানে চুক্তি — “কী” আর “কীভাবে” আলাদা

বাড়ির দেয়ালের বিদ্যুতের সকেটের কথা ভাবুন। ফ্যান, ফোনের charger বা ইস্ত্রি — যার plug সকেটে আঁটে, সেটিই চলে। সকেট জানে না কোন যন্ত্র লাগানো হলো; যন্ত্রও জানে না বিদ্যুৎ এল কোন কেন্দ্র থেকে, সৌর প্যানেল না জেনারেটর থেকে। দুই পক্ষ শুধু একটি চুক্তি মানে: এত volt, এই আকারের পিন। এই চুক্তিটিই interface.

Software-এ interface হলো একটি module, class বা service বাইরের জগৎকে যা কথা দেয় — কোন operation আছে, প্রতিটি কী নেয়, কী ফেরত দেয়, কখন ব্যর্থ হয়। ভেতরে সেটি কীভাবে করা হলো, তা implementation. পর্ব ২৫-এ (modularity, coupling আর cohesion) দেখেছেন, David Parnas ১৯৭২ সালে বলেছিলেন module ভাগ করুন এমনভাবে, যাতে বদলাতে পারে এমন সিদ্ধান্তগুলো ভেতরে লুকানো থাকে — information hiding. Interface সেই লুকানোর দেয়াল; যা দেয়ালের বাইরে দেখা যায়, শুধু সেটুকুই চুক্তি।

Program to an interface, not an implementation

১৯৯৪ সালের Design Patterns বইয়ে Gamma, Helm, Johnson আর Vlissides (Gang of Four) নকশার একটি মূল নীতি লেখেন: “Program to an interface, not an implementation.” অর্থাৎ variable, parameter আর field-এর type হিসেবে নির্দিষ্ট class নয়, বরং চুক্তিটুকু ব্যবহার করুন। এই নীতিটি program to an interface নামে পরিচিত।

from typing import Protocol

class Notifier(Protocol):                 # the contract: WHAT a notifier can do
    def send(self, phone: str, text: str) -> bool: ...

class SmsNotifier:                        # one HOW (no inheritance needed)
    def send(self, phone: str, text: str) -> bool:
        print(f"SMS to {phone}: {text}")
        return True

def remind_due(members: list[str], notifier: Notifier) -> int:
    return sum(notifier.send(p, "Kisti due on the 10th") for p in members)

একটি কাল্পনিক সমবায় সমিতির সঞ্চয় app-এর কিস্তি মনে করিয়ে দেওয়ার function remind_due শুধু জানে “যার send(phone, text) আছে”। আগামী বছর SMS-এর বদলে app notification বা email এলে remind_due-এর একটি অক্ষরও বদলাতে হবে না; test-এ একটি নকল notifier দিলেই চলবে (পর্ব ৪৯-এ test double). Python-এর typing.Protocol (PEP 544, Python ৩.৮) এই চুক্তিকে type checker-এর কাছে লিখে রাখে — class-টিকে Notifier থেকে উত্তরাধিকার নিতে হয় না, শুধু আকার মিললেই হয়; একে বলে structural typing. Java বা C#-এ একই কাজ করে interface keyword, যেখানে class-কে স্পষ্টভাবে implements লিখতে হয় (nominal typing). বিস্তারিত দেখুন Python কোর্সের ABC, duck typing আর Protocol আর Java কোর্সের abstract class আর interface পর্বে।

২ · ভালো interface-এর নকশা — ছোট, সুসংহত, ভুল করা কঠিন

একবার interface প্রকাশ হলে অন্যরা তার ওপর কোড লেখেন, তাই ভুল interface বদলানো ভেতরের কোড বদলানোর চেয়ে অনেক দামি। কয়েকটি পরীক্ষিত নির্দেশনা:

• ছোট আর সুসংহত। একটি interface একটি দায়িত্বের কথা বলবে। বিশটি method-এর “সব কাজের” interface সবাইকে এমন method-এর ওপর নির্ভর করায়, যা তাঁরা ব্যবহারই করেন না — পর্ব ২৮-এর interface segregation (SOLID ২) আর পর্ব ২৫-এর cohesion ঠিক এই কথা বলে।
• ঠিকভাবে ব্যবহার সহজ, ভুলভাবে ব্যবহার কঠিন। Scott Meyers-এর নামে প্রচলিত একটি পরামর্শ (তাঁর Effective C++-এর পরের সংস্করণগুলোতে আর একটি প্রবন্ধে এভাবে লেখা বলে উদ্ধৃত হয়): “Make interfaces easy to use correctly and hard to use incorrectly.” ভুল হলে দোষ ব্যবহারকারীর নয়, interface-এর নকশার — এই দৃষ্টিভঙ্গিটাই মূল।
• নাম দিয়ে অর্থ। process(data) কিছুই বলে না; reserve_seat(trip_id, seat_no) বলে। কিছু ফেরত দেওয়া প্রশ্ন (balance()) আর অবস্থা বদলানো আদেশ (withdraw()) আলাদা রাখার নীতি — পর্ব ২৬-এর command-query separation (নকশার নীতি) — নামকেও সৎ রাখে।
• এক ধরনের error. একই library-র একটি function ব্যর্থ হলে None, আরেকটি -1, তৃতীয়টি exception দিলে ব্যবহারকারীকে প্রতিটির নিয়ম মুখস্থ করতে হয়। পুরো interface-এ একটি নিয়ম রাখুন (§৬)।
• একক আর সীমা type-এ বা নামে। set_timeout(30) — সেকেন্ড না মিলিসেকেন্ড? set_timeout(seconds=30) বা একটি Duration type এই প্রশ্ন মুছে দেয়। ১৯৯৯ সালের Mars Climate Orbiter-এর ঘটনা (পর্ব ০২, software-এর ইতিহাস) মনে করিয়ে দেয়, একক নিয়ে অস্পষ্ট interface কতটা দামি হতে পারে।

৩ · Design by contract — precondition, postcondition আর invariant

ফরাসি কম্পিউটার বিজ্ঞানী Bertrand Meyer ১৯৮০-র দশকের মাঝামাঝি Eiffel নামে একটি object-oriented ভাষা নকশা করেন, যার কেন্দ্রে একটি ধারণা: প্রতিটি class আর method তার ব্যবহারকারীর সাথে একটি ব্যবসায়িক চুক্তির মতো সম্পর্কে থাকে। তিনি এর নাম দেন design by contract (DbC); ধারণাটি বিস্তারিত আসে তাঁর বই Object-Oriented Software Construction-এ (প্রথম সংস্করণ ১৯৮৮, দ্বিতীয় ১৯৯৭)। এর শিকড় আরও পুরোনো — ১৯৬৯ সালে C. A. R. Hoare-এর Hoare triple {P} S {Q}: P সত্য অবস্থায় S চালালে শেষে Q সত্য হবে। Meyer এই গাণিতিক চিন্তাকে প্রতিদিনের কোডে নামিয়ে আনেন। (“Design by Contract” শব্দবন্ধটি Eiffel Software-এর trademark হিসেবেও নিবন্ধিত বলে জানা যায়, তাই অনেক লেখায় “contract programming” বলা হয়।)

চুক্তির তিনটি অংশ:

Precondition, postcondition আর class invariant — তিনটিই সত্য-মিথ্যা প্রকাশ (boolean expression). Postcondition প্রায়ই কাজের আগের অবস্থার সাথে তুলনা করে; Eiffel-এ এজন্য আছে old keyword: old balance মানে method শুরুর মুহূর্তে balance-এর মান। এই old value ছাড়া “ঠিক amount টাকাই কমেছে” লেখা যায় না। পর্ব ২২-এ (use case আর user story) use case-এর precondition আর guarantee দেখেছিলেন — চিন্তাটি একই, কিন্তু সেখানে পুরো ব্যবহারকারী-লক্ষ্যের স্তরে; এখানে একটি method-এর স্তরে, কোডে যাচাই করা যায় এমনভাবে।

class ACCOUNT
feature
    balance: INTEGER

    withdraw (amount: INTEGER)
        require
            positive: amount > 0
            enough_money: amount <= balance
        do
            balance := balance - amount
        ensure
            deducted: balance = old balance - amount
        end
invariant
    never_negative: balance >= 0
end

প্রতিটি শর্তের একটি নাম (positive, enough_money) আছে — ভাঙলে error বার্তায় সেই নাম আসে। নিচের চিত্রটি Meyer-এর বইয়ে ব্যবহৃত ধরনের একটি সারণি: চুক্তিতে প্রতিটি পক্ষের একটি দায়িত্ব আর একটি লাভ, আর এক পক্ষের দায়িত্বই অন্য পক্ষের লাভ।

একটি চুক্তি-যাচাই করা ডাক ঠিক কোন ক্রমে চলে, নিচের stepper-এ withdraw(300) দিয়ে দেখুন। শুরুতে balance ১০০০ টাকা।

1withdraw(amount):2  require 0 < amount ≤ balance3  old_balance = balance4  balance = balance - amount5  ensure balance == old_balance - amount6  invariant balance ≥ 0

৪ · Contract ভাঙলে দোষ কার — আর কোডে তা ধরা

DbC-এর সবচেয়ে কাজের দিক হলো দায় ভাগ করা। একটি contract ভাঙা মানে সবসময় একটি bug — ব্যবহারকারীর ভুল input বা network বন্ধ হওয়া নয়, বরং কোনো programmer-এর ভুল। কোন শর্ত ভাঙল দেখে সরাসরি বলা যায় কার কোড ঠিক করতে হবে। নিচের stepper ছয়টি পরিস্থিতি একে একে দেখায়।

Python-এ একটি contract decorator

Eiffel ছাড়া অন্য ভাষায় এই যাচাই নিজে বসাতে হয়। নিচের প্রোগ্রামে একটি decorator @contract(pre=…, old=…, post=…) method-কে মুড়ে দেয়: আগে precondition, তারপর old মানের ছবি, তারপর আসল কাজ, শেষে postcondition. দুই ধরনের ভাঙনের জন্য দুটি আলাদা exception class — নাম দেখেই দায় বোঝা যায়। একই WITHDRAW চুক্তি parent আর subclass দুটিতেই বসানো, কারণ চুক্তিটি interface-এর, কোনো একটি implementation-এর নয়।

import functools, inspect
class ContractError(Exception): pass
class PreconditionError(ContractError): pass    # blame: the caller
class PostconditionError(ContractError): pass   # blame: the supplier (implementation)
def contract(pre=None, old=None, post=None):
    def wrap(fn):
        sig = inspect.signature(fn)
        @functools.wraps(fn)
        def inner(*args, **kwargs):
            a = sig.bind(*args, **kwargs).arguments
            call = f"{type(a['self']).__name__}.{fn.__name__}(amount={a.get('amount')})"
            if pre and not pre(**a):
                raise PreconditionError(f"caller broke pre of {call}")
            snapshot = old(**a) if old else None      # 'old' value, taken BEFORE the body runs
            result = fn(*args, **kwargs)
            if post and not post(snapshot, result, **a):
                raise PostconditionError(f"supplier broke post of {call}")
            return result
        return inner
    return wrap

WITHDRAW = contract(pre=lambda self, amount: 0 < amount <= self.balance,
                    old=lambda self, amount: self.balance,
                    post=lambda old, result, self, amount: self.balance == old - amount == result)
class Account:
    def __init__(self, balance): self.balance = balance
    @WITHDRAW
    def withdraw(self, amount): self.balance -= amount; return self.balance
class FeeAccount(Account):                      # a "clever" subclass with a hidden fee
    @WITHDRAW
    def withdraw(self, amount): self.balance -= amount + 5; return self.balance

for acct, amt in [(Account(1000), 300), (Account(1000), 5000), (FeeAccount(1000), 300)]:
    try: print(type(acct).__name__, amt, "->", acct.withdraw(amt))
    except ContractError as e: print(f"{type(e).__name__}: {e} | balance {acct.balance}")

Account 300 -> 700
PreconditionError: caller broke pre of Account.withdraw(amount=5000) | balance 1000
PostconditionError: supplier broke post of FeeAccount.withdraw(amount=300) | balance 695

৫ · Eiffel ছাড়া contract — assert, validation আর defensive programming

বেশিরভাগ ভাষায় contract-এর জন্য আলাদা keyword নেই; চারটি সাধারণ হাতিয়ার দিয়ে কাজ চলে:

1. Assertion: assert শর্ত, "বার্তা" — শর্ত মিথ্যা হলে AssertionError. ভেতরের invariant আর “এমন হওয়ার কথাই নয়” ধরনের অনুমান লেখার জন্য চমৎকার। কিন্তু Python-কে -O flag দিয়ে চালালে (বা PYTHONOPTIMIZE environment variable দিলে) সব assert statement compile-এর সময়েই বাদ পড়ে, আর __debug__ হয়ে যায় False. C-তে NDEBUG দিলে assert একইভাবে উধাও হয়, আর Java-তে assertion ডিফল্টভাবে বন্ধই থাকে (-ea দিয়ে চালু করতে হয়)।
2. সবসময়-চলা check: if not …: raise ValueError(…) — flag যা-ই হোক, চলবেই। বাইরে থেকে আসা data যাচাইয়ের (input validation) একমাত্র নিরাপদ পথ।
3. Type hint আর Protocol: amount: int বা §১-এর Notifier — mypy বা pyright-এর মতো checker চালানোর আগেই আকারের ভুল ধরে। কিন্তু Python চলার সময় type hint নিজে কিছু যাচাই করে না, আর “amount > 0”-এর মতো আচরণের শর্ত type-এ প্রকাশ করা যায় না।
4. Contract decorator বা library: §৪-এর মতো নিজে লেখা, বা icontract, deal-এর মতো third-party library (নাম আর API নিজে যাচাই করে নিন)। কিছু ভাষায় এটি ভাষারই অংশ: Ada ২০১২-এর Pre/Post aspect, আর C++26-এর জন্য contract-এর প্রস্তাব গৃহীত হয়েছে বলে জানা যায়।

নিচের প্রোগ্রাম একই ছাড়ের (discount) function দুইভাবে লেখে — একটি assert দিয়ে input যাচাই করে (ভুল পথ), অন্যটি সবসময়-চলা check দিয়ে। -O flag-এর ওপর নির্ভর না করে, Python-এর built-in compile(..., optimize=1) দিয়ে একই কোড ঠিক সেভাবে compile করা হয়েছে, যেভাবে python -O করত।

SRC = '''
def discount_assert(price, pct):
    assert 0 <= pct <= 100, f"pct out of range: {pct}"   # assert used as input check (wrong)
    return price * (100 - pct) // 100

def discount_checked(price, pct):
    if not 0 <= pct <= 100:                               # real validation: always runs
        raise ValueError(f"pct must be 0..100, got {pct}")
    return price * (100 - pct) // 100
'''
for level in (0, 1):            # optimize=1 compiles the same code the way "python -O" would
    ns = {}
    exec(compile(SRC, "shop.py", "exec", optimize=level), ns)
    for name in ("discount_assert", "discount_checked"):
        try:
            print(f"optimize={level} {name}(500, 150) -> {ns[name](500, 150)}")
        except (AssertionError, ValueError) as e:
            print(f"optimize={level} {name}(500, 150) -> {type(e).__name__}: {e}")

def apply_coupon(cart_total, coupon):                     # internal invariant: a fine use of assert
    new_total = cart_total - min(coupon, cart_total)
    assert 0 <= new_total <= cart_total, "coupon logic is broken"
    return new_total
print("apply_coupon(300, 500) ->", apply_coupon(300, 500), "| __debug__ =", __debug__)

optimize=0 discount_assert(500, 150) -> AssertionError: pct out of range: 150
optimize=0 discount_checked(500, 150) -> ValueError: pct must be 0..100, got 150
optimize=1 discount_assert(500, 150) -> -250
optimize=1 discount_checked(500, 150) -> ValueError: pct must be 0..100, got 150
apply_coupon(300, 500) -> 0 | __debug__ = True

Defensive programming বনাম design by contract

Defensive programming বলে: প্রতিটি function প্রতিটি input সন্দেহ করবে, সব যাচাই করবে। DbC বলে উল্টো: precondition caller-এর দায়, supplier আবার যাচাই করে কোড ভারী করবে না (Meyer একে বলেন non-redundancy). দুই চিন্তার বিরোধ মেটে একটি ধারণায় — trust boundary:

৬ · Error handling — exception, error code আর Result

§৪-এর শেষ পরিস্থিতি — server সাড়া দিচ্ছে না — contract ভাঙা নয়, তবু caller-কে জানাতে হবে। ব্যর্থতা জানানোর তিনটি প্রধান পথ আছে, প্রত্যেকটির নিজস্ব দাম:

Go মাঝামাঝি পথ নেয় — function দুটি মান ফেরত দেয়, value, err, আর caller-কে if err != nil লিখতে হয়। নিচের প্রোগ্রাম একটি কাল্পনিক দোকানের পণ্য-তালিকা import-এ দুই পথ পাশাপাশি দেখায়: প্রতিটি লাইন নাম,পরিমাণ,দাম; তিনটি ধাপ — পরিমাণ পড়া, দাম পড়া, সীমা (সর্বোচ্চ ১০) যাচাই।

// Fictional shop import: "name,qty,price" lines -> order total
const lines = ["rice,2,60", "oil,x,180", "sugar,1,-5", "salt,3,20", "dal,40,95"];

// Style A: exceptions — one try around the whole batch
function parseA(line) {
  const [name, q, p] = line.split(",");
  if (!/^\d+$/.test(q)) throw new Error(`bad qty "${q}"`);
  if (!(Number(p) > 0)) throw new Error(`bad price "${p}"`);
  if (Number(q) > 10) throw new Error(`qty ${q} over limit 10`);
  return { name, qty: Number(q), price: Number(p) };
}
let totalA = 0, doneA = 0;
try { for (const l of lines) { const it = parseA(l); totalA += it.qty * it.price; doneA++; } }
catch (e) { console.log(`A: stopped after ${doneA} line(s): ${e.message}; total ${totalA}`); }

// Style B: Result values — every stage returns Ok or Err
const Ok = value => ({ ok: true, value }), Err = error => ({ ok: false, error });
let skipped = 0;                          // stages an Err passed through untouched
const then = (r, f) => { if (r.ok) return f(r.value); skipped++; return r; };
const qty   = ([n, q, p]) => /^\d+$/.test(q) ? Ok([n, Number(q), p]) : Err(`bad qty "${q}"`);
const price = ([n, q, p]) => Number(p) > 0 ? Ok([n, q, Number(p)]) : Err(`bad price "${p}"`);
const limit = ([n, q, p]) => q <= 10 ? Ok({ name: n, qty: q, price: p }) : Err(`qty ${q} over limit 10`);
const results = lines.map(l => then(then(qty(l.split(",")), price), limit));

const good = results.filter(r => r.ok).map(r => r.value);
const bad = results.map((r, i) => r.ok ? null : `line ${i + 1}: ${r.error}`).filter(Boolean);
console.log(`B: ${good.length} ok, total ${good.reduce((s, it) => s + it.qty * it.price, 0)}`);
bad.forEach(m => console.log("  " + m));
console.log(`B: errors skipped ${skipped} later stage(s) on the way out`);

A: stopped after 1 line(s): bad qty "x"; total 120
B: 2 ok, total 180
  line 2: bad qty "x"
  line 3: bad price "-5"
  line 5: qty 40 over limit 10
B: errors skipped 3 later stage(s) on the way out

যে পথই নিন — পাঁচটি নিয়ম

• Error কখনো চুপচাপ গিলবেন না। except Exception: pass বা খালি catch {} — bug লুকানোর সবচেয়ে নিশ্চিত উপায়, যাকে বলে swallowed exception. সামলাতে না পারলে ধরবেন না; ধরলে log করে, প্রসঙ্গ যোগ করে আবার তুলুন (Python-এ raise … from e, JavaScript-এ new Error(msg, { cause: e }))।
• Fail fast. ভুল অবস্থা দেখামাত্র থামুন, যাতে ভুলটি যেখানে জন্মেছে তার কাছেই ধরা পড়ে — ভুল মান নিয়ে আরও দশটি function পার হয়ে database-এ পৌঁছানোর আগে। Fail fast-এর ধারণা পর্ব ২৬-এ দেখেছেন; Jim Shore-এর ২০০৪ সালের একটি IEEE Software প্রবন্ধ এই নামটিকে জনপ্রিয় করে বলে উদ্ধৃত হয়।
• Error-এর বংশতালিকা। একটি মূল class (SavingsError), তার নিচে InsufficientFunds, AccountLocked, BankUnavailable. Caller চাইলে নির্দিষ্টটি ধরেন, চাইলে সবগুলো একসাথে। এই error hierarchy interface-এর অংশ — documentation-এ লিখুন।
• Checked বনাম unchecked (Java). Java-তে checked exception (যেমন IOException) method-এর signature-এ throws দিয়ে ঘোষণা করতে হয়, আর caller-কে ধরতেই হয় বা আবার ঘোষণা করতে হয়; RuntimeException-এর উত্তরসূরিরা unchecked. সাধারণ চলতি নির্দেশনা: caller যা থেকে বাস্তবে সেরে উঠতে পারেন সেখানে checked, programming bug-এ unchecked. C#, Kotlin-এর মতো পরের ভাষাগুলো checked exception রাখেনি (ভাবনার প্রশ্ন ২)।
• বার্তা মানুষের জন্য। “Error occurred” কিছুই বলে না। ভালো বার্তা বলে কী হলো, কোন মান নিয়ে, আর কী করা যায়: pct must be 0..100, got 150. পাসওয়ার্ড, token বা পুরো কার্ড নম্বর বার্তায় বা log-এ রাখবেন না। কোডের ভেতরে error সামলানোর লেখার ধরন পর্ব ৪১-এ (clean code) আরও দেখবেন; HTTP API-তে এক ছাঁচের error-এর নকশা দেখুন System Design-এর REST API নকশা পর্বে।

৭ · Immutability — যে মান বদলায় না, তাকে নিয়ে ভাবা সহজ

পরীক্ষার খাতার খসড়া পাতায় আপনি কাটাকুটি করেন; ফেয়ার কপিতে নয়। দোকানের ছাপানো রসিদও তাই — ভুল হলে রসিদ ঘষে বদলানো হয় না, নতুন রসিদ দেওয়া হয়। Immutability মানে object তৈরির পরে তার অবস্থা আর বদলায় না; “বদল” চাইলে নতুন object তৈরি হয়। এতে তিনটি বড় লাভ:

• ভাবা সহজ: একটি Money(100) হাতে পেলে আপনি নিশ্চিত, অন্য কেউ পেছন থেকে এটিকে ৫০ বানাবে না। Invariant একবার constructor-এ যাচাই করলেই চিরকাল সত্য।
• Concurrency-তে নিরাপদ: একাধিক thread একই data একসাথে পড়লে কোনো race condition হয় না, কারণ কেউ লিখছেই না — lock লাগে না।
• নিরাপদে ভাগ করা আর key বানানো: Immutable মানকে dictionary-র key বা cache-এর চাবি বানানো যায়; Python-এ str, tuple, frozenset এজন্যই hashable.

Domain-driven design-এ (Eric Evans, ২০০৩) এমন মানকে বলে value object: পরিচয় নয়, মানই আসল — দুটি ১০০ টাকার নোট সমান, কোনটি কোনটি তাতে কিছু যায় আসে না। Python-এ @dataclass(frozen=True) (Python কোর্সের dataclass পর্ব), Java-তে record (Java-র record) এই কাজ সহজ করে। JavaScript-এ আছে Object.freeze — কিন্তু একটি বড় ফাঁদসহ।

// A frozen order from a fictional grocery app
const order = Object.freeze({ id: "A-17", total: 900,
  items: [{ sku: "rice", qty: 2 }], customer: { city: "Khulna" } });

order.total = 0;                          // sloppy mode: silently ignored
order.items.push({ sku: "oil", qty: 1 }); // nested array is NOT frozen
order.customer.city = "Dhaka";            // nested object is NOT frozen
console.log("shallow:", order.total, order.items.length, order.customer.city,
  Object.isFrozen(order), Object.isFrozen(order.items));

function deepFreeze(obj) {
  for (const v of Object.values(obj))
    if (v !== null && typeof v === "object" && !Object.isFrozen(v)) deepFreeze(v);
  return Object.freeze(obj);
}
const safe = deepFreeze({ id: "A-18", total: 450,
  items: [{ sku: "dal", qty: 1 }], customer: { city: "Sylhet" } });

safe.customer.city = "Dhaka";             // sloppy mode: silently ignored
try { safe.items.push({ sku: "egg", qty: 12 }); }   // push throws even in sloppy mode
catch (e) { console.log("push:", e.name); }
(function () {
  "use strict";                           // strict mode: every write to frozen data throws
  try { safe.total = 0; } catch (e) { console.log("strict:", e.name); }
})();
console.log("deep:", safe.total, safe.items.length, safe.customer.city,
  Object.isFrozen(safe.items[0]));

shallow: 900 2 Dhaka true false
push: TypeError
strict: TypeError
deep: 450 1 Sylhet true

Defensive copy — mutable জিনিস ঢোকা আর বেরোনোর সময়

সব কিছু immutable করা না গেলে সীমানায় কপি করুন। Constructor একটি list পেলে তার কপি রাখুন, যাতে caller পরে নিজের list বদলালে object-এর অবস্থা না বদলায়; getter ভেতরের list ফেরত না দিয়ে কপি বা tuple দিন। এই defensive copy §২-এর টেবিলের শেষ সারির সমাধান। Frozen dataclass-এর ভেতরেও list রাখলে সেটি বদলানো যায় — অনুশীলন ১-এ এর একটি উদাহরণ আছে। কপির খরচ আছে, তাই বড় data-র ক্ষেত্রে persistent data structure (যেখানে নতুন version পুরোনোর বেশিরভাগ অংশ ভাগ করে নেয়) একটি বিকল্প; বিস্তারিত Python কোর্সের mutability আর copy পর্বে।

৮ · Idempotent কাজ আর null-এর ব্যবস্থা

লিফটের বোতাম একবার চাপুন বা দশবার — লিফট একবারই আসে। কিন্তু চায়ের দোকানে “আরেক কাপ” দশবার বললে দশ কাপ আসে। প্রথমটি idempotent: একই কাজ একবার করা আর বহুবার করার ফল একই। Interface-এর চুক্তিতে এটি লিখে রাখা খুব জরুরি, কারণ network-এ “উত্তর আসেনি” মানে কাজ হয়নি — এমন নয়; হয়তো কাজ হয়েছে, শুধু উত্তর হারিয়েছে। Caller তখন আবার চেষ্টা (retry) করবেন, আর কাজটি idempotent না হলে সমিতির সদস্যের কিস্তি দুবার কাটা যাবে।

শেষ কৌশলটি — প্রতিটি অনুরোধে একটি অনন্য key, আর server আগে দেখা key-এর জন্য আগের ফল ফেরত দেয় — payment API-গুলোতে বহুল প্রচলিত। এর খুঁটিনাটি (key কতদিন রাখবেন, একই key-তে ভিন্ন body এলে কী করবেন) REST API নকশা পর্বে আছে; এখানে মূল কথা হলো idempotency interface-এর চুক্তির অংশ, ভেতরের খুঁটিনাটি নয়।

Null — “নেই” কীভাবে বলবেন

“এই ফোন নম্বরে কোনো সদস্য নেই” — কীভাবে জানাবেন? সবচেয়ে প্রচলিত উত্তর null/None, আর এর জনক Tony Hoare নিজেই ২০০৯ সালের একটি বক্তৃতায় ১৯৬৫ সালে ALGOL W-তে null reference যোগ করাকে তাঁর “billion-dollar mistake” বলেছিলেন। সমস্যা হলো null signature-এ দেখা যায় না: find_member(phone) -> Member পড়ে কেউ বোঝেন না এটি কখনো কখনো কিছুই দেবে না। তিনটি বিকল্প:

কোনটি বেছে নেবেন? “নেই” যদি স্বাভাবিক উত্তর হয় (খোঁজা), Optional; “নেই”-র একটি নিরীহ ডিফল্ট আচরণ থাকলে (ছাড় নেই = শূন্য ছাড়), Null Object; আর “নেই” যদি আসলে ভুল হয় (সদস্যের ID দিয়ে আনতে গিয়ে পাওয়া গেল না, অথচ ID আমাদের নিজেদের database থেকেই এসেছে), exception — নিজের নিয়ম ভাঙার কথা চুপচাপ None-এ লুকাবেন না।

৯ · Interface বদলানো — পুরোনো ব্যবহারকারী না ভেঙে

একটি interface একবার অন্যরা ব্যবহার শুরু করলে প্রতিটি বদলের প্রশ্ন একটাই: পুরোনো নিয়মে লেখা কোড কি এখনো চলবে? চললে পরিবর্তনটি backward compatible. DbC-র ভাষায় নিরাপদ বদলের নিয়ম পর্ব ২৮-এর Liskov নিয়মের মতোই: precondition দুর্বল করা (আগের চেয়ে বেশি input গ্রহণ) আর postcondition শক্ত করা (আগের চেয়ে বেশি প্রতিশ্রুতি) পুরোনো caller ভাঙে না; উল্টোটা ভাঙে। নতুন optional parameter, নতুন method, নতুন error subclass — সাধারণত নিরাপদ; parameter সরানো, নাম বদলানো, ফেরত মানের অর্থ বদলানো — breaking. পর্ব ১৮-এর SemVer (ভালো commit, tag আর release) এই পার্থক্যকেই version নম্বরে লেখে; data format আর schema-র ক্ষেত্রে একই প্রশ্নের উত্তর System Design-এর serialization আর schema পর্বে।

নিচের stepper একটি কাল্পনিক SMS library-র interface ধাপে ধাপে বদলায় — কোনো client না ভেঙে, শেষে একটি পরিকল্পিত MAJOR পর্যন্ত। এই কৌশলের প্রচলিত নাম parallel change বা expand-contract: আগে নতুনটি যোগ (expand), সবাই সরে গেলে পুরোনোটি সরানো (contract).

১০ · AI-এর যুগে interface আর contract

AI কোড-সহকারী দ্রুত function লেখে, কিন্তু চুক্তির প্রশ্নে তার ভুলগুলো খুব পরিচিত ধাঁচের। কারণ AI প্রায়ই শুধু “সুখের পথ” (happy path) দেখে, আর ইন্টারনেটে প্রচলিত অভ্যাস — ভালো-মন্দ মিলিয়ে — অনুকরণ করে।

AI-এর খসড়া হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি precondition caller নিজে যাচাই করতে পারেন; লুকানো অবস্থার ওপর কোনো শর্ত নেই
• কোনো except/catch error গিলে ফেলে না; প্রতিটি হয় সামলায়, নয় প্রসঙ্গ যোগ করে আবার তোলে
• Test suite python -O দিয়েও চালিয়েছি — validation একই আচরণ করে
• Contract ভাঙার test লিখেছি: ইচ্ছা করে ভুল implementation দিয়ে দেখেছি postcondition সত্যিই ধরে
• Public API-র diff আলাদা করে দেখেছি; breaking হলে version আর changelog সেই অনুযায়ী
• AI-এর বলা library, flag আর ইতিহাসের দাবি official documentation-এ মিলিয়েছি, আর library-র license দেখেছি
• Prompt-এ গ্রাহকের তথ্য, secret বা ভেতরের গোপন কোড দিইনি