Behavioral pattern ২ — state, iterator, chain of responsibility, mediator আর visitor

১ · দ্বিতীয় দল — কে কাকে কাজ দেবে, কে কার সাথে কথা বলবে

পর্ব ৩২-এ (design pattern কী) দেখেছেন, Gang of Four-এর ১৯৯৪ সালের Design Patterns বইয়ে ২৩টি pattern তিন দলে ভাগ করা: creational (object বানানো, পর্ব ৩৩), structural (object জোড়া দেওয়া, পর্ব ৩৪) আর behavioral — object-রা কীভাবে দায়িত্ব ভাগ করে আর একে অপরের সাথে কথা বলে। Behavioral দলে ১১টি pattern; পর্ব ৩৫-এ (Behavioral pattern ১) দেখেছেন strategy, observer, command আর template method. এই পর্বে বাকিগুলোর পাঁচটি বিস্তারিত, আর দুটি (Memento, Interpreter) এক লাইনে — যাতে পুরো তালিকা আপনার হাতে থাকে।

প্রতিটি pattern একই ছকে দেখব: উদ্দেশ্য (GoF-এর intent), সমস্যা, গঠন, কোড, ফলাফল (consequences) আর ফাঁদ.

২ · State — অবস্থা বদলালে আচরণ বদলায়

উদ্দেশ্য (GoF): “Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.” অর্থাৎ object-এর ভেতরের অবস্থা বদলালে তার আচরণও বদলাবে, আর বাইরে থেকে মনে হবে object-টির class-ই বদলে গেছে। এটিই State pattern. GoF-এর বইয়ে উদাহরণ ছিল একটি TCP connection — Established, Listen আর Closed অবস্থায় একই open() ডাকের অর্থ আলাদা।

সমস্যা: একই switch দশ জায়গায়

একটি কাল্পনিক উপজেলা গণগ্রন্থাগারের app নিন। একটি বইয়ের কপি তিনটি state-এ থাকতে পারে: Available (তাকে আছে), Reserved (কেউ সংরক্ষণ করেছেন) আর OnLoan (কেউ নিয়ে গেছেন)। ঘটনা (event) তিনটি: borrow, give_back আর reserve. ধার দেওয়া কপিতে কেউ সংরক্ষণ করলে কপিটি ফেরত এলে সরাসরি Reserved-এ যায়। পর্ব ২৩-এ (requirement modeling) একটি অর্ডারের জীবনচক্র state machine diagram-এ এঁকেছিলেন, আর পর্ব ৩০-এ (UML behaviour diagram) design-স্তরের state machine — entry, exit আর guard-সহ। এখানে প্রশ্ন কোডের: সেই ছবিটি কোডে কীভাবে লিখবেন?

প্রথম চেষ্টা প্রায় সবসময় একটি status field আর প্রতিটি method-এ if status == .... শুরুতে এটি ঠিকই আছে। কিন্তু অবস্থা আর ঘটনা বাড়লে একই শর্তের শিকল borrow, give_back, reserve, জরিমানার হিসাব, SMS পাঠানো — সবখানে ছড়িয়ে পড়ে। নতুন অবস্থা Lost এলে প্রতিটি জায়গা খুঁজে বদলাতে হয়; একটি ভুলে গেলে bug. পর্ব ২৭-এ (SOLID ১) এই গন্ধের নাম দেখেছেন — repeated switch — আর তার প্রতিকার polymorphism. State pattern ঠিক সেই প্রতিকারটি অবস্থার ক্ষেত্রে প্রয়োগ করে।

গঠন

তিনটি অংশ: (১) context — বাইরের জগৎ যে object-টি দেখে (Book), যার ভেতরে বর্তমান অবস্থার একটি object; (২) একটি State interface — প্রতিটি event-এর জন্য একটি method; (৩) প্রতিটি অবস্থার জন্য একটি concrete class, যা শুধু সেই অবস্থার আচরণ জানে। Context প্রতিটি event পেলে প্রশ্ন না করে বর্তমান state object-কে কাজটি দিয়ে দেয়।

কোড: State class বনাম একটি বড় switch

নিচের প্রোগ্রামে একই নিয়ম দুইভাবে লেখা। প্রথমটি State pattern: base class BookState-এর প্রতিটি event ডিফল্টভাবে InvalidTransition তোলে, আর প্রতিটি concrete state শুধু নিজের বৈধ event-গুলো override করে, পরের state object ফেরত দিয়ে। দ্বিতীয়টি Python-এর match দিয়ে একটি টেবিলের মতো switch. দুটিকে একই ছয়টি event দেওয়া হয়েছে, যার দুটি অবৈধ।

class InvalidTransition(Exception): pass
class BookState:                              # default: every event is invalid
    name = property(lambda self: type(self).__name__)
    def _no(self, ev): raise InvalidTransition(f"{ev} not allowed while {self.name}")
    def borrow(self, book):    self._no("borrow")
    def give_back(self, book): self._no("give_back")
    def reserve(self, book):   self._no("reserve")
class Available(BookState):
    def borrow(self, book):  return OnLoan()
    def reserve(self, book): return Reserved()
class Reserved(BookState):
    def borrow(self, book):  return OnLoan()   # only the reserving member, in real life
class OnLoan(BookState):
    def reserve(self, book): book.waiting = True; return self
    def give_back(self, book):
        nxt = Reserved() if book.waiting else Available(); book.waiting = False; return nxt
class Book:                                   # the context: delegates, never asks "which state?"
    def __init__(self): self.state, self.waiting = Available(), False
    def handle(self, ev):
        old = self.state.name
        try: self.state = getattr(self.state, ev)(self); print(f"{ev:9} {old:9} -> {self.state.name}")
        except InvalidTransition as e: print(f"{ev:9} {old:9} REJECTED: {e}")
def next_state(state, ev, waiting):           # the same rules as one big switch
    match (state, ev):
        case ("Available" | "Reserved", "borrow"): return "OnLoan", False
        case ("Available", "reserve"): return "Reserved", False
        case ("OnLoan", "reserve"): return "OnLoan", True
        case ("OnLoan", "give_back"): return ("Reserved" if waiting else "Available"), False
        case _: return None                   # None = invalid; every caller must remember to check
book, sw = Book(), ("Available", False)
for ev in ["borrow", "reserve", "borrow", "give_back", "give_back", "borrow"]:
    book.handle(ev)
    sw = next_state(sw[0], ev, sw[1]) or sw
print("state classes end in:", book.state.name, "| switch ends in:", sw[0])

borrow    Available -> OnLoan
reserve   OnLoan    -> OnLoan
borrow    OnLoan    REJECTED: borrow not allowed while OnLoan
give_back OnLoan    -> Reserved
give_back Reserved  REJECTED: give_back not allowed while Reserved
borrow    Reserved  -> OnLoan
state classes end in: OnLoan | switch ends in: OnLoan

নিচের stepper-এ ওপরের ছয়টি event একে একে দেখুন — প্রতিবার কোন class-এর কোন method চলছে।

1Book.handle(ev): state = state.ev(book)2Available.borrow  → OnLoan()3Available.reserve → Reserved()4Reserved.borrow   → OnLoan()5OnLoan.reserve    → waiting=True; self6OnLoan.give_back  → Reserved / Available7BookState._no     → raise InvalidTransition

Transition কে ঠিক করবে — context, না state?

GoF দুটি পথই আলোচনা করে। State-রা নিজেরা পরের state ঠিক করলে (ওপরের কোড) নতুন state যোগ করা সহজ আর প্রতিটি নিয়ম তার অবস্থার পাশেই থাকে; কিন্তু state class-গুলো একে অপরকে চেনে, তাই তাদের মধ্যে coupling তৈরি হয়। Context বা একটি টেবিল transition ঠিক করলে (যেমন {(Available, borrow): OnLoan}) পুরো জীবনচক্র এক জায়গায় পড়া যায় আর state class-রা শুধু আচরণ রাখে; কিন্তু নতুন state এলে টেবিলও বদলাতে হয়। নিয়ম সহজ আর স্থির হলে টেবিল; প্রতিটি অবস্থায় আচরণ জটিল হলে state class নিজেরাই.

State বনাম Strategy — একই ছবি, ভিন্ন গল্প

UML-এ State আর পর্ব ৩৫-এর Strategy প্রায় হুবহু এক: context-এর ভেতরে একটি interface-এর object, যার কাছে কাজ পাঠানো হয়। তফাতটা উদ্দেশ্যে আর কে বদলায় তাতে।

ফলাফল: প্রতিটি অবস্থার আচরণ এক class-এ (cohesion বাড়ে); নতুন অবস্থা যোগ করা প্রায়ই নতুন class যোগ (পর্ব ২৭-এর open-closed); transition স্পষ্ট হয়, কারণ state পরিবর্তন মানে একটি field-এ নতুন object বসানো। খরচ: class-এর সংখ্যা বাড়ে, আর পুরো জীবনচক্র এক নজরে দেখতে কয়েকটি file খুলতে হয়।

৩ · Iterator — ভেতর না দেখিয়ে একে একে

উদ্দেশ্য (GoF): “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.” একটি collection-এর উপাদানগুলো ক্রমানুসারে পাওয়ার উপায় দেওয়া, কিন্তু collection-টি ভেতরে array, linked list, গাছ, database না network-এর পাতা — তা না জানিয়ে। এটিই Iterator pattern.

সমস্যা আর গঠন

Iterator না থাকলে ঘোরানোর কোড collection-এর গঠন জানে: array হলে for (i = 0; i < n; i++), linked list হলে while (node) node = node.next, গাছ হলে recursion. Collection বদলালে সব ঘোরানোর কোড বদলাতে হয়। Iterator দুটি দায়িত্ব আলাদা করে: iterable (collection) জানে কীভাবে নতুন iterator বানাতে হয়, আর iterator মনে রাখে কতদূর পড়া হলো। একই collection-এর ওপর তাই একসাথে দুটি স্বাধীন iterator চলতে পারে।

• External iterator: client নিজে next() ডেকে এগোয় আর ইচ্ছামতো থামে। Python আর JavaScript-এর for লুপ ভেতরে এটিই করে।
• Internal iterator: collection নিজে ঘোরে আর প্রতিটি উপাদানে client-এর দেওয়া function চালায় — JavaScript-এর forEach. লেখা সহজ, কিন্তু মাঝপথে থামা বা দুটি collection একসাথে মিলিয়ে ঘোরানো কঠিন (forEach-এ break চলে না)।

Python-এর iterator protocol আর generator

Python-এ iterator protocol ভাষারই অংশ (PEP 234, Python ২.১): iterable-এর __iter__ একটি iterator ফেরত দেয়; iterator-এর __next__ পরের মান দেয়, আর শেষ হলে StopIteration তোলে। for, list(), sum(), unpacking — সবাই এই চুক্তি ব্যবহার করে।

class Shelf:                              # an iterable: can make fresh iterators
    def __init__(self, books): self._books = list(books)
    def __iter__(self): return ShelfIterator(self._books)

class ShelfIterator:                      # an iterator: remembers where it is
    def __init__(self, books): self._books, self._i = books, 0
    def __iter__(self): return self
    def __next__(self):
        if self._i >= len(self._books): raise StopIteration
        self._i += 1
        return self._books[self._i - 1]

def shelf_gen(books):                     # the same iterator, written as a generator
    for b in books:
        yield b

s = Shelf(["Gitanjali", "Padma Nadir Majhi"])
print(list(s), list(s))                   # two passes work: two fresh iterators
it = iter(s); print(next(it), next(it), next(it, "done"))

['Gitanjali', 'Padma Nadir Majhi'] ['Gitanjali', 'Padma Nadir Majhi']
Gitanjali Padma Nadir Majhi done

Shelf iterable, ShelfIterator iterator — দুবার list(s) চালালে দুটি নতুন iterator তৈরি হয়, তাই দুবারই পুরো তালিকা আসে। শেষে next(it, "done") শেষ হয়ে গেলে exception-এর বদলে ডিফল্ট মান দেয়। কিন্তু এত লেখা প্রায়ই দরকার হয় না: shelf_gen-এর মতো একটি generator function (PEP 255, Python ২.২) একই কাজ করে। yield-এ এসে function থেমে থাকে, তার local variable-সহ; পরের next()-এ সেখান থেকেই আবার চলে। Iterator-এর “কতদূর পড়া হলো” মনে রাখার দায়িত্ব তখন ভাষা নিজেই নেয়। বিস্তারিত দেখুন Python কোর্সের iterator, generator আর yield পর্বে।

JavaScript-এ Symbol.iterator আর lazy পাতা-আনা

JavaScript-এ (ES2015 থেকে) একই চুক্তি: যার [Symbol.iterator]() method একটি iterator দেয়, সেটি for...of, spread [...x] আর destructuring-এ চলে; iterator-এর next() দেয় { value, done }. function* generator এর সহজ রূপ। নিচের প্রোগ্রামে একটি কাল্পনিক দোকানের API ২০টি পণ্য ৫টি করে পাতায় দেয়। Catalog-এর iterator পাতাগুলো লুকিয়ে রাখে — client শুধু পণ্য দেখে — আর পাতা আনে শুধু দরকার হলে। এই “দরকার হলে তবেই” নীতির নাম lazy evaluation. Data একই থাকার জন্য একটি seeded PRNG (mulberry32, seed 36) ব্যবহার করা হয়েছে।

// Fictional shop API: 20 products, served 5 per page. Seeded PRNG = same data every run.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(36);
const DB = Array.from({ length: 20 }, (_, i) => ({ id: i + 1, price: 50 + Math.floor(rand() * 450) }));
let fetched = 0;
function fetchPage(p, size = 5) {             // stands in for one network call
  fetched++; console.log(`  [api] GET /products?page=${p}`);
  return { items: DB.slice((p - 1) * size, p * size), next: p * size < DB.length ? p + 1 : null };
}
class Catalog {                               // client never sees pages, only items
  *[Symbol.iterator]() {
    try {
      for (let p = 1; p !== null; ) { const page = fetchPage(p); yield* page.items; p = page.next; }
    } finally { console.log("  [catalog] iterator closed"); }
  }
}
function* filter(it, ok) { for (const x of it) if (ok(x)) yield x; }
function* take(it, n) { if (n <= 0) return; for (const x of it) { yield x; if (--n === 0) return; } }

const cheap = take(filter(new Catalog(), x => x.price < 150), 2);
console.log("pipeline built, pages fetched:", fetched);
for (const item of cheap) console.log("got #" + item.id, "price", item.price);
console.log("pages fetched:", fetched, "of", DB.length / 5);

const it = new Catalog()[Symbol.iterator]();  // the protocol by hand: next() -> {value, done}
console.log(JSON.stringify(it.next()), "| total fetched now:", fetched);
console.log("eager copy:", [...new Catalog()].length, "items | total fetched now:", fetched);

pipeline built, pages fetched: 0
  [api] GET /products?page=1
got #4 price 123
  [api] GET /products?page=2
got #10 price 140
  [catalog] iterator closed
pages fetched: 2 of 4
  [api] GET /products?page=1
{"value":{"id":1,"price":480},"done":false} | total fetched now: 3
  [api] GET /products?page=1
  [api] GET /products?page=2
  [api] GET /products?page=3
  [api] GET /products?page=4
  [catalog] iterator closed
eager copy: 20 items | total fetched now: 7

ঘোরানোর সময় collection বদলানো

Iterator-এর সবচেয়ে পরিচিত ফাঁদ হলো concurrent modification — iterator চলার সময়েই collection বদলানো। Iterator মনে রাখে “আমি এখন ২ নম্বর ঘরে”; নিচে ঘর সরে গেলে সে ভুল জায়গায় দাঁড়িয়ে থাকে।

nums = [1, 2, 2, 3]
for x in nums:
    if x == 2:
        nums.remove(x)           # shifts the list under the iterator
print(nums)                      # [1, 2, 3]  -- one 2 survived!

stock = {"rice": 5, "oil": 0}
for item in stock:
    stock["salt"] = 9            # RuntimeError: dictionary changed size during iteration

List-এর ক্ষেত্রে Python চুপচাপ একটি উপাদান বাদ দেয় — প্রথম 2 মোছার পর দ্বিতীয় 2 এক ঘর বাঁয়ে সরে আসে, আর iterator পরের ঘরে চলে যায়। Dict-এর ক্ষেত্রে Python সতর্ক — আকার বদলালে RuntimeError. Java-র collection-এর iterator একইভাবে ConcurrentModificationException তোলে, যাকে বলে fail-fast iterator (documentation নিজেই বলে, এটি “best-effort” — সবসময় ধরা পড়ার নিশ্চয়তা নেই)। সমাধান: নতুন collection বানান ([x for x in nums if x != 2]), কপির ওপর ঘোরান (for x in list(nums)), নয়তো পরিবর্তনগুলো জমিয়ে লুপ শেষে প্রয়োগ করুন।

ফলাফল: collection-এর গঠন বদলালেও client-এর কোড বদলায় না; একই collection-এ একাধিক স্বাধীন ঘোরানো; lazy হলে অসীম ধারা (যেমন প্রতিটি নতুন log লাইন) বা বিশাল data-ও অল্প memory-তে। খরচ ও ফাঁদ: generator একবারই ঘোরানো যায় — দ্বিতীয়বার ঘোরালে খালি পাবেন; আর lazy কাজের error ঘটে ব্যবহারের মুহূর্তে, তৈরির মুহূর্তে নয়।

৪ · Chain of Responsibility — হাতে হাতে অনুরোধ

উদ্দেশ্য (GoF): “Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.” পাঠানো পক্ষকে গ্রহণকারীর সাথে বেঁধে না রেখে একাধিক object-কে সামলানোর সুযোগ দেওয়া — তাদের একটি শিকলে সাজিয়ে, যতক্ষণ না কেউ সামলায়। এটিই Chain of Responsibility. GoF-এর উদাহরণ ছিল একটি app-এর প্রসঙ্গভিত্তিক help: বোতামে help চাইলে বোতাম না পারলে dialog, dialog না পারলে পুরো application উত্তর দেয়।

গঠন

একটি Handler interface বা abstract class, যার একটি handle(req) আর পরের handler-এর একটি reference (next, ০ বা ১টি)। প্রতিটি concrete handler দুটি কাজের একটি করে: নিজে উত্তর দেয় — তখন শিকল সেখানেই থামে, যাকে বলে short-circuit — নয়তো next-কে দেয়। Client শুধু প্রথম handler-টি চেনে।

আজকের রূপ: web framework-এর middleware

GoF-এর শিকলে একটি handler সামলালে বাকিরা কিছুই করে না। আধুনিক web framework-এর middleware একটু আলাদা ধাঁচের: প্রতিটি ধাপ কিছু কাজ করে (log, login যাচাই, সময় মাপা) আর তারপর next() ডেকে পরের ধাপে পাঠায়, অথবা নিজেই উত্তর দিয়ে শিকল থামায়। Express-এর (req, res, next), Koa-র async next (যাকে “onion” মডেল বলা হয়, কারণ await next()-এর পরের কোড ফেরার পথে চলে), Django-র middleware, Java Servlet-এর Filter আর FilterChain, ASP.NET Core-এর pipeline — সবই এই ধারার। তাত্ত্বিকভাবে এগুলো GoF-এর শুদ্ধ CoR আর Intercepting Filter বা Decorator-এর মাঝামাঝি (ভাবনার প্রশ্ন ৩)।

নিচের প্রোগ্রামে একটি কাল্পনিক মুদি-অর্ডার API-র চারটি ধাপ: auth (login আছে কি?) → rateLimit (একজন বেশি অনুরোধ পাঠাচ্ছেন কি?) → validate (পরিমাণ ১–১০ কেজি কি?) → createOrder. প্রতিটি ধাপ হয় একটি উত্তর ফেরত দেয়, নয় next(). req.trail লিখে রাখে অনুরোধটি কোন কোন ধাপ পেরোল। সংক্ষেপের জন্য rate limit এখানে সময়ের জানালা ছাড়া শুধু গোনে; আসল token bucket বা sliding window দেখুন System Design-এর rate limiting পর্বে।

// Fictional grocery-order API: each handler either answers (short-circuit) or calls next()
function auth(req, next) {
  if (req.token !== "tok-rina") return { status: 401, body: "login required" };
  req.user = "rina"; return next();
}
const hits = {};                               // requests per user (no time window, to keep it short)
function rateLimit(req, next) {
  hits[req.user] = (hits[req.user] ?? 0) + 1;
  return hits[req.user] > 3 ? { status: 429, body: "too many requests" } : next();
}
function validate(req, next) {
  const ok = Number.isInteger(req.qty) && req.qty >= 1 && req.qty <= 10;
  return ok ? next() : { status: 400, body: "qty must be 1..10" };
}
function createOrder(req) { return { status: 201, body: `order: ${req.qty} kg rice for ${req.user}` }; }
const notFound = () => ({ status: 404, body: "no handler" });   // the default: chain always ends

function chain(...handlers) {
  return req => {
    req.trail = [];
    const run = i => {
      const h = handlers[i] ?? notFound;      // ran past the last handler? fall back to default
      req.trail.push(h.name); return h(req, () => run(i + 1));
    };
    return run(0);
  };
}
const app = chain(auth, rateLimit, validate, createOrder);
for (const req of [{ qty: 2 }, { token: "tok-rina", qty: 2 }, { token: "tok-rina", qty: 50 },
                   { token: "tok-rina", qty: 1 }, { token: "tok-rina", qty: 3 }]) {
  const res = app(req);
  console.log(res.status, res.body.padEnd(28), "<-", req.trail.join(" > "));
}
const broken = chain(auth, validate);         // someone forgot the final handler
console.log(broken({ token: "tok-rina", qty: 1 }).status, "<- default handler caught it");

401 login required               <- auth
201 order: 2 kg rice for rina    <- auth > rateLimit > validate > createOrder
400 qty must be 1..10            <- auth > rateLimit > validate
201 order: 1 kg rice for rina    <- auth > rateLimit > validate > createOrder
429 too many requests            <- auth > rateLimit
404 <- default handler caught it

নিচের stepper-এ তৃতীয় অনুরোধটি (qty: 50) শিকল ধরে হাঁটে, তারপর পঞ্চমটির সাথে তুলনা।

৫ · Mediator — সবার মাঝে একজন সমন্বয়ক

উদ্দেশ্য (GoF): “Define an object that encapsulates how a set of objects interact.” একদল object কীভাবে একে অপরের সাথে কাজ করবে, সেই নিয়মগুলো একটি আলাদা object-এ রাখা; সদস্যরা (GoF বলে colleague) একে অপরকে সরাসরি চেনে না, শুধু সমন্বয়ককে চেনে। এটিই Mediator pattern. GoF-এর উদাহরণ ছিল একটি font বাছাইয়ের dialog box: তালিকায় font বাছলে নমুনা-লেখা বদলায়, কিছু checkbox নিষ্ক্রিয় হয় — widget-রা একে অপরকে না ডেকে একটি “director”-কে জানায়।

নিচে একটি কাল্পনিক অফিস-chat-এর ছোট উদাহরণ। Member অন্য কোনো সদস্যকে চেনে না, শুধু room-কে; কাকে বার্তা যাবে, সেই নিয়ম পুরোটা ChatRoom-এ।

class ChatRoom:                          # the mediator
    def __init__(self): self.members = {}
    def join(self, m): self.members[m.name] = m; m.room = self
    def send(self, sender, text, to=None):
        for name, m in self.members.items():
            if name != sender.name and to in (None, name):
                m.receive(sender.name, text)

class Member:                            # a colleague: knows only the room
    def __init__(self, name): self.name, self.room = name, None
    def say(self, text, to=None): self.room.send(self, text, to)
    def receive(self, frm, text): print(f"{self.name} <- {frm}: {text}")

room = ChatRoom()
for n in ["Rina", "Karim", "Tuli"]: room.join(Member(n))
room.members["Rina"].say("meeting at 4")
room.members["Karim"].say("ok", to="Rina")

Karim <- Rina: meeting at 4
Tuli <- Rina: meeting at 4
Rina <- Karim: ok

কাল যদি নিয়ম আসে “অফিস সময়ের পরে বার্তা জমা থাকবে” বা “Tuli-কে বার্তা গেলে তাঁর সহকারীও পাবেন”, বদলাবে শুধু ChatRoom.send; কোনো Member-এর কোড ছোঁয়া লাগবে না। UI-তে mediator খুব সাধারণ: একটি form-এর controller ঠিক করে “দেশ বাছলে জেলার তালিকা বদলাবে, জেলা বাছলে উপজেলা” — dropdown-রা একে অপরকে চেনে না। পর্ব ৩৯-এর MVC-র controller-এ এই চিন্তাটি আবার দেখবেন।

Mediator, Observer আর Facade — তফাত কোথায়

• Observer (পর্ব ৩৫): একটি subject থেকে অনেক observer-এর দিকে এক-মুখী খবর; subject জানে না কে কী করবে। Mediator-এ যোগাযোগ দুই-মুখী, আর সমন্বয়ের নিয়ম mediator-এর ভেতরে। বাস্তবে mediator প্রায়ই observer দিয়েই বানানো হয় — colleague-রা ঘটনা প্রকাশ করে, mediator শোনে।
• Facade (পর্ব ৩৪, Structural pattern): একটি জটিল subsystem-এর সামনে সহজ দরজা — এক-মুখী, subsystem-এর অংশগুলো facade-কে চেনে না। Mediator-এর colleague-রা mediator-কে চেনে আর তাকে জানায়।

৬ · Visitor — কাঠামো স্থির, কাজ নতুন

উদ্দেশ্য (GoF): “Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.” একটি object-কাঠামোর উপাদানগুলোর ওপর একটি কাজকে আলাদা object হিসেবে রাখা, যাতে উপাদানের class না বদলেই নতুন কাজ যোগ করা যায়। এটিই Visitor pattern. GoF-এর উদাহরণ ছিল compiler: abstract syntax tree-র node-গুলো স্থির, কিন্তু তার ওপর কাজ অনেক — type যাচাই, code বানানো, সুন্দর করে ছাপা।

সমস্যা

একটি ছোট হিসাবযন্ত্রের expression tree নিন: Num, Add, Mul. (2 + 3) * 4 হলো একটি Mul, যার বাঁয়ে একটি Add আর ডানে Num(4) — পর্ব ৩৪-এর Composite-এর মতো গাছ। এখন কাজ চাই: মান বের করা, সুন্দর করে ছাপা, গভীরতা মাপা, পরে হয়তো LaTeX-এ রূপান্তর। প্রতিটি কাজের জন্য প্রতিটি node class-এ একটি method যোগ করলে node class-গুলো সব কাজের খুঁটিনাটিতে ভরে যায়, আর নতুন কাজ মানে সব class খোলা। Visitor উল্টো দিকে ভাগ করে: প্রতিটি কাজ একটি class, যার ভেতরে প্রতিটি node type-এর জন্য একটি visit_… method.

Double dispatch — দুই ধাপের বাছাই

বেশিরভাগ OOP ভাষায় x.f(y) লিখলে কোন f চলবে, তা ঠিক হয় শুধু x-এর চলার সময়ের type দেখে — একে বলে single dispatch. কিন্তু Visitor-এ উত্তর নির্ভর করে দুটি type-এর ওপর: কোন node (Add না Num) আর কোন কাজ (Evaluate না Pretty). সমাধান দুটি ডাক: আগে node.accept(visitor) — node-এর type অনুযায়ী বাছাই; তারপর node নিজেই visitor.visit_add(self) ডাকে — visitor-এর type অনুযায়ী বাছাই। এই কৌশলের নাম double dispatch; Smalltalk-প্রসঙ্গে Dan Ingalls-এর ১৯৮৬ সালের OOPSLA প্রবন্ধ এটি পরিচিত করে বলে উদ্ধৃত হয়।

from dataclasses import dataclass
from functools import singledispatch

class Node:                                      # dispatch 1: on the node's class
    def accept(self, visitor): return getattr(visitor, "visit_" + type(self).__name__.lower())(self)
@dataclass
class Num(Node): v: int
@dataclass
class Add(Node): l: Node; r: Node
@dataclass
class Mul(Node): l: Node; r: Node
class Evaluate:                                  # dispatch 2: on the visitor object
    def visit_num(self, n): return n.v
    def visit_add(self, n): return n.l.accept(self) + n.r.accept(self)
    def visit_mul(self, n): return n.l.accept(self) * n.r.accept(self)
class Pretty:
    def visit_num(self, n): return str(n.v)
    def visit_add(self, n): return f"({n.l.accept(self)} + {n.r.accept(self)})"
    def visit_mul(self, n): return f"{n.l.accept(self)} * {n.r.accept(self)}"
tree = Mul(Add(Num(2), Num(3)), Num(4))
print(tree.accept(Pretty()), "=", tree.accept(Evaluate()))
@singledispatch                                  # alternative 1: no accept() needed in nodes
def depth(node): raise TypeError(f"depth() has no rule for {type(node).__name__}")
@depth.register
def _(node: Num): return 1
@depth.register(Add)
@depth.register(Mul)
def _(node): return 1 + max(depth(node.l), depth(node.r))
def count_nums(node):                            # alternative 2: structural pattern matching
    match node:
        case Num(): return 1
        case Add(l, r) | Mul(l, r): return count_nums(l) + count_nums(r)
print("depth:", depth(tree), "| numbers:", count_nums(tree))
try: depth(3.5)
except TypeError as e: print("TypeError:", e)

(2 + 3) * 4 = 20
depth: 3 | numbers: 3
TypeError: depth() has no rule for float

নিচের stepper-এ tree.accept(Evaluate())-এর প্রতিটি ডাক দেখুন — প্রতিবার দুটি বাছাই।

1Node.accept(v): getattr(v, "visit_" + cls)(self)2visit_num(n): return n.v3visit_add(n): n.l.accept(self) + n.r.accept(self)4visit_mul(n): n.l.accept(self) * n.r.accept(self)

ফলাফল — আর বিখ্যাত দুর্বলতা

সুবিধা: নতুন কাজ যোগ সহজ (একটি নতুন visitor); একটি কাজের সব কোড এক class-এ; visitor ঘোরার পথে অবস্থা জমাতে পারে (যেমন type যাচাইয়ের সময় variable-এর তালিকা)। দুর্বলতা: নতুন element type যোগ করা কঠিন — Sub যোগ করলে প্রতিটি visitor-এ একটি visit_sub লিখতে হয়; ১০টি visitor থাকলে ১০টি class খুলতে হয়। তাই GoF-এর পরামর্শ: কাঠামো স্থির আর কাজ বেশি বদলালে Visitor; কাঠামো ঘন ঘন বদলালে নয়। এটি একটি গভীর প্রশ্নের একটি দিক, যার নাম Philip Wadler ১৯৯৮ সালে দেন expression problem — নতুন data type আর নতুন কাজ, দুটোই পুরোনো কোড না ছুঁয়ে যোগ করা যায় কি না (ভাবনার প্রশ্ন ৪)।

৭ · Memento আর Interpreter — GoF-এর তালিকা সম্পূর্ণ

• Memento: encapsulation না ভেঙে একটি object-এর ভেতরের অবস্থার ছবি তুলে রাখা, যাতে পরে সেই অবস্থায় ফেরা যায় — text editor-এর undo বা খেলার “save point”-এর ভিত্তি (পরীক্ষার খাতার খসড়া পাতাটি রেখে দেওয়ার মতো)। পর্ব ৩৫-এর Command-এর সাথে প্রায়ই জোড়ায় আসে।
• Interpreter: একটি ছোট ভাষার প্রতিটি ব্যাকরণ-নিয়মকে একটি class বানিয়ে, সেই class-গুলোর গাছ দিয়ে বাক্যের অর্থ বের করা — ওপরের Num/Add/Mul-এ একটি interpret() method দিলেই সেটি Interpreter; ব্যাকরণ বড় হলে parser generator ভালো।

এখন GoF-এর ১১টি behavioral pattern-ই আপনার দেখা হলো:

৮ · কোনটি কখন — গুলিয়ে ফেলা জোড়া আর অতি-ব্যবহার

Pattern-এর নাম মুখস্থ থাকলেও বাস্তবে সমস্যা হয় দুটি জায়গায়: কাছাকাছি দেখতে দুটি pattern গুলিয়ে ফেলা, আর যেখানে দরকার নেই সেখানে pattern বসানো। প্রথমটির জন্য একটি তুলনা:

দ্বিতীয়টির জন্য একটি প্রশ্ন সবসময় করুন: “এই pattern ছাড়া কোডটি কি আজ সত্যিই কষ্টদায়ক?” দুটি অবস্থার জন্য State class, তিন লাইনের validation-এর জন্য পাঁচ handler-এর শিকল, দুটি form field-এর জন্য mediator, বা একটি কাজের জন্য Visitor — সবগুলোই পর্ব ২৬-এর over-engineering. Pattern প্রায়ই সবচেয়ে ভালো আসে refactoring-এর পথে: যখন একই switch তৃতীয়বার লিখতে যাচ্ছেন, বা একটি class পাঁচটি অন্য class-কে সরাসরি ডাকছে — তখন। পর্ব ৪২-এ (code smell আর refactoring) “Replace Conditional with Polymorphism” ধরনের ধাপগুলো দেখবেন; আর পর্ব ৩৭-এ (dependency injection আর composition) দেখবেন, এই পর্বের context, handler আর visitor-গুলো বাইরে থেকে কীভাবে জুড়ে দেওয়া যায়।

৯ · AI-এর যুগে behavioral pattern

“এই কোডে State pattern লাগাও” বললে AI কোড-সহকারী কয়েক সেকেন্ডে পাঁচটি class লিখে দেয়। কিন্তু pattern-টি আদৌ দরকার কি না, সে প্রায় কখনো জিজ্ঞেস করে না।

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

• Pattern ছাড়া সরল রূপের সাথে তুলনা করেছি; pattern-টি কোন বাস্তব কষ্ট কমাচ্ছে, এক বাক্যে বলতে পারি
• State-এর ক্ষেত্রে state diagram (পর্ব ৩০) আর কোড মিলিয়েছি; প্রতিটি তীর আর অবৈধ জোড়ার test আছে
• Generator বা iterator-এ counter বসিয়ে দেখেছি কাজ সত্যিই lazy; লুপের ভেতরে collection বদলানো হয়নি
• Middleware-এর প্রতিটি পথ ঠিক একটি উত্তর দেয়; ক্রম (auth, rate limit, validate) সচেতনভাবে বাছা; শেষে default handler
• AI-এর বলা API (singledispatch, Symbol.asyncIterator ইত্যাদি) official documentation-এ মিলিয়েছি আর চালিয়ে দেখেছি
• UML diagram-এর তীর, ত্রিভুজ আর multiplicity পর্ব ২৯-এর নিয়মে যাচাই করেছি
• কোড কোথা থেকে এল, তার license দেখেছি; prompt-এ secret বা গ্রাহকের তথ্য দিইনি