Behavioral pattern ১ — strategy, observer, command আর template method

১ · Behavioral pattern — কে সিদ্ধান্ত নেয়, কে কাকে ডাকে

পর্ব ৩২-এ (Design pattern কী) দেখেছেন, একটি design pattern হলো বারবার আসা একটি নকশা-সমস্যার নাম দেওয়া, পরীক্ষিত সমাধানের ছাঁচ। পর্ব ৩৩-এর creational pattern-এর প্রশ্ন ছিল “object কে বানাবে”, পর্ব ৩৪-এর structural pattern-এর প্রশ্ন “object-গুলো কীভাবে জোড়া লাগবে”। এবার তৃতীয় প্রশ্ন: object-গুলো কীভাবে কাজ ভাগ করবে আর একে অপরের সাথে কথা বলবে। এই দলের নাম behavioral pattern.

চারটি pattern-কে চারটি পরিচিত দৃশ্যে ভাবুন:

প্রতিটি pattern-কে আমরা একই ছকে দেখব: উদ্দেশ্য (GoF-এর ভাষায় intent), সমস্যা (pattern না থাকলে কোড কেমন হয়), কাঠামো (কোন ভূমিকায় কোন object), কোড, ফলাফল (কী পাবেন, কী দাম দেবেন — GoF-এর consequences) আর ফাঁদ। সব উদাহরণ একটি কাল্পনিক অনলাইন বাজার অ্যাপের — চাল, ডাল, ডেলিভারি আর দামের খবর।

২ · Strategy — একই কাজ, বদলযোগ্য পদ্ধতি

উদ্দেশ্য। GoF-এর ভাষায়: একদল algorithm সংজ্ঞায়িত করুন, প্রতিটিকে আলাদা করে মুড়ে রাখুন, আর তাদের বদলযোগ্য করুন; তাহলে algorithm তার ব্যবহারকারী থেকে স্বাধীনভাবে বদলাতে পারে। বইয়ে এর আরেক নাম Policy. Strategy pattern-এর নাম আপনি পর্ব ২৭-এ (SOLID ১) প্রথম শুনেছেন — সেখানে courier-এর খরচের class-গুলো একটি registry-তে নিবন্ধিত হয়ে open-closed principle মেনেছিল। এই অংশে সেই উদাহরণ আবার নয়; এখানে দেখব strategy কে বাছাই করে, কখন বদলায়, আর function দিয়ে কত হালকাভাবে লেখা যায়।

সমস্যা। একটি কাল্পনিক মুদি-ডেলিভারি অ্যাপের checkout-এ ডেলিভারি ফি হিসাব হয়। নিয়ম অনেক: সমান ফি, দূরত্ব অনুযায়ী, সদস্যদের জন্য ৫০০ টাকার বেশি অর্ডারে ফ্রি, বৃষ্টির দিনে দেড় গুণ। সব নিয়ম checkout()-এর ভেতরে if-else দিয়ে লিখলে function লম্বা হয়, প্রতিটি নিয়ম আলাদা করে test করা যায় না, আর নিয়ম যোগ করতে মূল checkout খুলতে হয়।

কাঠামো। তিনটি ভূমিকা: Strategy — একটি চুক্তি (এখানে “order দিলে ফি ফেরত দাও”); ConcreteStrategy — প্রতিটি নিয়ম; আর Context (context) — যে object একটি strategy ধরে রাখে আর কাজের সময় তাকে ডাকে। Context জানে না কোন নিয়ম চলছে; সে শুধু চুক্তি জানে — এটাই polymorphism.

Function-ই strategy

Java-র পুরোনো সংস্করণে strategy মানে প্রায় সবসময় একটি interface আর কয়েকটি class. কিন্তু JavaScript আর Python-এ function নিজেই একটি মান — variable-এ রাখা যায়, argument-এ পাঠানো যায় (first-class function). একটিমাত্র method-এর strategy-কে তাই একটি function হিসেবে লেখাই স্বাভাবিক। আর যে function অন্য function নেয় বা ফেরত দেয় (higher-order function), তা দিয়ে strategy-কে মুড়ে নতুন strategy বানানো যায়। নিচের কোডে freeOver আর rainSurge ঠিক সেটাই করে।

// Strategy as plain functions: delivery-fee rules of a fictional grocery app.
// Every rule has the same shape: (order) => fee in taka.
const flat = () => 60;
const byDistance = o => 30 + 10 * Math.ceil(o.km);
const freeOver = (limit, base) => o => (o.total >= limit ? 0 : base(o)); // wraps a rule
const rainSurge = base => o => Math.round(base(o) * 1.5);                // wraps a rule

class Checkout {                         // the context: knows only "a rule"
  constructor(rule) { this.rule = rule; }
  setRule(rule) { this.rule = rule; }    // swap the strategy at runtime
  fee(order) { return this.rule(order); }
}

function pickRule({ member, raining }) { // the choice lives in ONE place
  let rule = member ? freeOver(500, byDistance) : byDistance;
  return raining ? rainSurge(rule) : rule;
}

const orders = [{ id: "A", km: 2.5, total: 350 }, { id: "B", km: 6, total: 800 }];
const co = new Checkout(flat);
const show = label =>
  console.log(label.padEnd(18), orders.map(o => `${o.id}=${co.fee(o)}`).join("  "));

show("flat");
const contexts = [
  { member: false, raining: false },
  { member: true, raining: false },
  { member: true, raining: true },
  { member: false, raining: true },
];
for (const ctx of contexts) {
  co.setRule(pickRule(ctx));
  show(`member=${ctx.member ? "Y" : "N"} rain=${ctx.raining ? "Y" : "N"}`);
}

flat               A=60  B=60
member=N rain=N    A=60  B=90
member=Y rain=N    A=60  B=0
member=Y rain=Y    A=90  B=0
member=N rain=Y    A=90  B=135

ফলাফল আর ফাঁদ

• লাভ: algorithm-এর পরিবার এক জায়গায়, শর্তের শাখা কম, নতুন নিয়ম মানে নতুন function বা class (পর্ব ২৭-এর open-closed principle), আর চলার সময় বদলানো যায়।
• দাম: caller-কে জানতে হয় কোন strategy কখন দিতে হবে — বাছাইয়ের দায় কোথাও যেতেই হবে। Object-এর সংখ্যা বাড়ে।
• ফাঁদ ১ — মোটা চুক্তি: কোনো strategy-র বাড়তি data লাগলে সবার চুক্তিতে parameter বাড়ানোর লোভ হয়। GoF-ও এই দামের কথা বলে: সব strategy একই interface ভাগ করে, তাই সরল strategy-কেও এমন তথ্য নিতে হয় যা তার লাগে না। একটি order object পাঠানো (যেমন এখানে) সাধারণত সবচেয়ে সহজ সমাধান।
• ফাঁদ ২ — একটিমাত্র রূপের strategy: নিয়ম একটি, বদলের প্রমাণ নেই — তবু interface, factory আর config. এটি পর্ব ২৬-এর YAGNI-র লঙ্ঘন; একটি সাধারণ function রাখুন।
• ফাঁদ ৩ — strategy-র ভেতরে লুকানো অবস্থা: একটি strategy যদি নিজের ভেতরে গণনা জমায়, তবে দুটি checkout একই object ভাগ করলে ফল মিশে যায়। Strategy যত stateless, তত নিরাপদ।

৩ · Observer — একটি ঘটনা, অনেক শ্রোতা

উদ্দেশ্য। GoF: object-দের মধ্যে এক-থেকে-অনেক নির্ভরতা সংজ্ঞায়িত করুন, যাতে একটি object-এর অবস্থা বদলালে তার ওপর নির্ভরশীল সবাই আপনা থেকে খবর পায় আর হালনাগাদ হয়। বইয়ে এর আরও দুটি নাম: Dependents আর Publish-Subscribe. Observer pattern সম্ভবত সবচেয়ে বেশি ব্যবহৃত pattern — browser-এর প্রতিটি click handler এর একটি রূপ।

সমস্যা। বাজার অ্যাপে চালের দাম বদলালে তিনটি কাজ হতে হয়: দাম ৪০০ টাকার নিচে নামলে গ্রাহককে SMS, admin dashboard-এ নতুন সংখ্যা, আর একটি log. সরল সমাধান: setPrice()-এর ভেতরে সরাসরি sms.send(), dashboard.update(), logger.write() ডাকা। এতে দামের class তিনটি অংশকে চেনে — পর্ব ২৫-এর ভাষায় বেশি coupling. চতুর্থ কোনো শ্রোতা (ধরুন একটি push notification) যোগ করতে দামের class খুলতে হয়, আর dashboard ছাড়া দামের class test-ও করা যায় না।

কাঠামো। দুই ভূমিকা। Subject — যার অবস্থার খবর দরকার; সে শ্রোতাদের একটি তালিকা রাখে, আর subscribe (GoF-এ attach), unsubscribe (detach) আর notify দেয়। Observer — একটি ছোট চুক্তি, সাধারণত একটি update() method; JavaScript-এ প্রায়ই শুধু একটি callback function. Subject শুধু চুক্তি জানে, শ্রোতাদের আসল class নয়।

Push বনাম pull

খবর দেওয়ার সময় data কীভাবে যাবে, তার দুটি ধরন GoF-এ আছে। Push model-এ subject নিজেই বদলের তথ্য পাঠায়: update("rice-5kg", 395). Pull model-এ subject শুধু বলে “আমি বদলেছি” — update(feed) — আর observer নিজের দরকারমতো feed.price পড়ে নেয়। Push-এ observer-কে subject-এর ভেতরটা জানতে হয় না, কিন্তু subject-কে আন্দাজ করতে হয় কার কী লাগবে। Pull-এ subject সরল থাকে, কিন্তু প্রতিটি observer subject-এর interface-এর ওপর নির্ভর করে, আর “কী বদলাল” খুঁজতে তাকে বাড়তি কাজ করতে হয়। বাস্তবে মিশ্র রূপ বেশি দেখা যায়: একটি ছোট event object, যার ভেতরে ঘটনার নাম আর মূল তথ্য — browser-এর click event যেমন।

ক্রম আর exception — একজনের ভুলে সবাই যেন না থামে

Observer-এর দুটি সূক্ষ্ম প্রশ্ন প্রায়ই ভুলে যাওয়া হয়। প্রথম: ক্রম। বেশিরভাগ বাস্তবায়ন নিবন্ধনের ক্রমে ডাকে, কিন্তু GoF-এর observer ক্রমের কোনো প্রতিশ্রুতি দেয় না। “Dashboard আগে, তারপর SMS” — এমন নির্ভরতা থাকলে সেটা লুকানো coupling; দরকার হলে সেটা স্পষ্ট করুন (দুটি আলাদা ঘটনা, বা একজন অন্যজনকে ডাকে)। দ্বিতীয়: exception. একটি সরল loop-এ তৃতীয় observer error ছুড়লে চতুর্থজন কখনো খবর পায় না, আর error-টি setPrice()-এর caller-এর কাছে গিয়ে পৌঁছায় — যে হয়তো শুধু দাম বসাতে চেয়েছিল। নিরাপদ notify প্রতিটি ডাক try-এর ভেতরে রাখে, ব্যর্থতা জমা রাখে, সবাইকে ডাকা শেষে জানায় বা log করে। তবে error চুপচাপ গিলে ফেলা (swallowed exception) আরেক বিপদ — জমা রাখা error কোথাও দেখাতেই হবে।

নিচের stepper-এ অংশ ৪-এর কোডের প্রথম অর্ধেক ধাপে ধাপে চলছে। তিনজন শ্রোতা নিবন্ধনের ক্রমে আছে: SMS, dashboard, আর একটি logger যার disk ভরা।

৪ · Observer-এর ফাঁদ — unsubscribe, memory leak আর event emitter

Observer-এর সবচেয়ে চেনা bug-টি কোনো error দেখায় না। একটি screen খোলার সময় subject-এ নিবন্ধন করল, বন্ধ হওয়ার সময় unsubscribe করতে ভুলে গেল। Subject-এর তালিকায় তার callback থেকে গেল, আর callback-এর ভেতর দিয়ে পুরো screen-এর object-ও। Garbage collector সেটি মুছতে পারে না, কারণ subject এখনো তাকে ধরে আছে — এটাই memory leak. এমন “মৃত অথচ তালিকায় জীবিত” শ্রোতাকে বলে lapsed listener. শুধু memory নয় — প্রতিটি নতুন খবরে বন্ধ screen-গুলোও কাজ করে: অকারণ redraw, দুবার SMS, বা বন্ধ হয়ে যাওয়া জিনিসে লিখতে গিয়ে অদ্ভুত error.

নিচের কোডের প্রথম অর্ধেক অংশ ৩-এর stepper-এ দেখেছেন। দ্বিতীয় অর্ধেকে একটি product page খোলার সময় subscribe করে; “অসতর্ক” page বন্ধ হওয়ার সময় কিছু করে না, “সতর্ক” page unsubscribe করে। তিনবার খোলা-বন্ধের পরে শ্রোতা গোনা হয়।

// Observer: a price feed in a fictional online bazaar app.
class PriceFeed {                                  // the subject
  #observers = new Set();
  constructor(item, price) { this.item = item; this.price = price; }
  subscribe(fn) { this.#observers.add(fn); return () => this.#observers.delete(fn); }
  get count() { return this.#observers.size; }
  setPrice(p) {
    this.price = p;
    const list = [...this.#observers], failed = []; // snapshot of the list
    for (const fn of list) {
      try { fn(this.item, p); }                    // push model: data goes with the call
      catch (e) { failed.push(e.message); }        // one bad observer must not stop the rest
    }
    console.log(`  -> called ${list.length}, failed ${failed.length}` +
                (failed.length ? ` (${failed.join("; ")})` : ""));
  }
}
const rice = new PriceFeed("rice-5kg", 420);
rice.subscribe((item, p) => { if (p < 400) console.log(`  SMS: ${item} now ${p} taka`); });
rice.subscribe((item, p) => console.log(`  dashboard: ${item} = ${p}`));
const stopLogger = rice.subscribe(() => { throw new Error("logger: disk full"); });
console.log("price 395:"); rice.setPrice(395);
stopLogger();
console.log("price 410:"); rice.setPrice(410);
// A product page subscribes when it opens. Forgetting to unsubscribe = a leak.
const openPage = (feed, id, careful) => {
  const stop = feed.subscribe((item, p) => console.log(`  page#${id} redraws ${p}`));
  return careful ? stop : () => {};                // close(): the careless page does nothing
};
for (const careful of [false, true]) {
  const feed = new PriceFeed("dal-1kg", 140);
  for (let id = 1; id <= 3; id++) openPage(feed, id, careful)();  // open, then close
  console.log(`${careful ? "careful" : "careless"}: 3 pages closed, listeners = ${feed.count}`);
  feed.setPrice(150);
}

price 395:
  SMS: rice-5kg now 395 taka
  dashboard: rice-5kg = 395
  -> called 3, failed 1 (logger: disk full)
price 410:
  dashboard: rice-5kg = 410
  -> called 2, failed 0
careless: 3 pages closed, listeners = 3
  page#1 redraws 150
  page#2 redraws 150
  page#3 redraws 150
  -> called 3, failed 0
careful: 3 pages closed, listeners = 0
  -> called 0, failed 0

Leak ঠেকানোর অভ্যাস

• জোড়ায় লিখুন: যেখানে subscribe, তার পাশেই unsubscribe-এর জায়গা — screen-এর “বন্ধ” বা component-এর “মুছে যাওয়া” ধাপে। Code review-তে (পর্ব ৪৪) প্রতিটি subscribe-এর জোড়া খুঁজুন।
• শ্রোতার আয়ু subject-এর চেয়ে ছোট হলে বিশেষ সতর্কতা: দীর্ঘজীবী subject (পুরো অ্যাপের দামের feed) আর স্বল্পজীবী শ্রোতা (একটি page) — leak-এর ক্লাসিক জুটি।
• Browser-এ: removeEventListener কাজ করে শুধু একই function reference দিলে; তাই inline arrow function দিয়ে যোগ করলে পরে সরানো যায় না। { once: true } একবার চলেই সরে যায়, আর নতুন browser-এ { signal } option দিয়ে একটি AbortController-এর এক ডাকে অনেক listener একসাথে সরানো যায়। বিস্তারিত JavaScript কোর্সের event আর memory leak পর্বে।
• Weak reference: কিছু ব্যবস্থা শ্রোতাকে weak reference-এ রাখে (Python-এর weakref.WeakSet/WeakMethod, JavaScript-এর WeakRef), যাতে শ্রোতা অন্য কোথাও ব্যবহৃত না হলে মুছে যেতে পারে। এটি সুরক্ষা-জাল, নকশার বিকল্প নয়: garbage collector কখন চলবে তা অনিশ্চিত, ততক্ষণ মৃত শ্রোতা খবর পেতেই পারে।

Event emitter আর DOM event — observer প্রতিদিন

বাস্তবে আপনি observer বেশিরভাগ সময় নিজে লেখেন না, একটি তৈরি event emitter ব্যবহার করেন: Node.js-এর EventEmitter (on, off, emit) বা browser-এর addEventListener. প্রতিটি ঘটনার নামে (যেমন "price", "click") আলাদা শ্রোতার তালিকা — একটি subject-এ অনেক ধরনের খবর। প্রতিটি শ্রোতা একটি event listener. তবে দুটির exception-এর আচরণ আলাদা, আর এই পার্থক্য interview-তেও আসে:

MVC, pub/sub আর observer-এর সীমা

Observer-এর জন্ম আসলে user interface-এর প্রয়োজন থেকে। ১৯৭০-এর দশকের শেষে Xerox PARC-এ Smalltalk-এর জন্য Trygve Reenskaug যে Model-View-Controller ধারণা দেন, তাতে model (data) জানে না কোন view তাকে দেখাচ্ছে; model বদলালে নির্ভরশীল view-দের খবর দেয় — ঠিক observer. এই সম্পর্ক, আর MVP ও MVVM-এ তার রূপ, পর্ব ৩৯-এ (MVC, MVP আর MVVM).

আরেকটি পার্থক্য মনে রাখুন। Observer-এ subject নিজের শ্রোতাদের সরাসরি ধরে রাখে, সাধারণত একই প্রোগ্রামের ভেতরে, প্রায়ই synchronous. Publish-subscribe ব্যবস্থায় মাঝখানে একটি broker বা topic থাকে: প্রকাশক জানে না কে শুনছে, শ্রোতাও জানে না কে পাঠিয়েছে, আর বার্তা প্রায়ই asynchronous, network পেরিয়ে, আলাদা machine-এ যায়। Service-এর মধ্যে এমন বার্তার নকশা — fan-out, delivery-র নিশ্চয়তা, choreography — System Design কোর্সের Pub/sub আর event-driven architecture পর্বে আছে; এখানে আমরা প্রোগ্রামের ভেতরের নকশাতেই থাকছি। একই প্রোগ্রামের ভেতরে অনেক subject আর অনেক শ্রোতার মাঝে একটি কেন্দ্রীয় “event bus” রাখলে সেটি mediator-এর দিকে যায় (পর্ব ৩৬)।

৫ · Command — অনুরোধকে একটি object বানানো

উদ্দেশ্য। GoF: একটি অনুরোধকে object হিসেবে মুড়ে রাখুন; তাহলে client-কে ভিন্ন ভিন্ন অনুরোধ দিয়ে সাজানো যায়, অনুরোধ সারিতে রাখা বা log করা যায়, আর undo করা যায় এমন কাজ সমর্থন করা যায়। বইয়ে এর অন্য নাম Action আর Transaction. Command pattern-এর মূল কৌশল একটি বাক্যে: “এখনই করো” ডাককে “করার জিনিস”-এ বদলে দেওয়া।

সমস্যা। একটি কাল্পনিক বাজার অ্যাপের admin panel-এ পণ্যের বিবরণ লেখার ছোট একটি editor. Toolbar-এর বোতাম, keyboard shortcut আর menu — তিনটিই একই কাজ করে (লেখা ঢোকানো, মোছা)। প্রতিটি বোতামের handler সরাসরি document বদলালে: কাজটি তিন জায়গায় লেখা হয়, undo করতে হলে কী বদলেছিল তা কেউ জানে না, আর কোন admin কোন বদল করেছেন তার log রাখার কোনো এক জায়গা নেই।

কাঠামো। চার ভূমিকা। Command — চুক্তি: execute(), আর undo চাইলে undo(). ConcreteCommand — একটি নির্দিষ্ট অনুরোধ, সাথে তার সব তথ্য (কোথায়, কী লেখা)। Receiver — যে আসলে কাজটি জানে (এখানে Document). Invoker — যে command চালায় আর ইতিহাস রাখে (এখানে Editor); বোতাম বা shortcut শুধু একটি command বানিয়ে invoker-কে দেয়। এই বানানোর কাজ যে করে, GoF তাকে Client বলে।

Undo আর redo — দুটি stack

Command undo-র সবচেয়ে পরিচিত বাস্তবায়ন দুটি stack দিয়ে, যাকে বলা যায় undo/redo stack: নতুন command চালালে সেটি undo stack-এর ওপরে যায়। Undo মানে ওপরেরটি তুলে তার undo() ডাকা আর redo stack-এ রাখা। Redo মানে redo stack থেকে তুলে আবার execute(). আর একটি নিয়ম, যা অনেকে ভুলে যান: নতুন command এলে redo stack খালি হয় — পুরোনো “ভবিষ্যৎ” আর বৈধ নয়, কারণ লেখা এখন অন্য পথে চলে গেছে।

Undo করতে হলে command-কে জানতে হবে কী উল্টাতে হবে। Insert-এর জন্য সহজ — যতগুলো অক্ষর ঢুকিয়েছি, ততগুলো মুছব। কিন্তু Delete-এর জন্য মোছার আগে মুছে ফেলা লেখাটি মনে রাখতে হবে, নইলে ফেরত আনা অসম্ভব। নিচের stepper-এ অংশের কোডটির প্রথম আটটি ধাপ।

from dataclasses import dataclass, replace
class Document:                                  # receiver: really edits the text
    def __init__(self): self.text = ""
    def insert(self, pos, s): self.text = self.text[:pos] + s + self.text[pos:]
    def delete(self, pos, n):
        gone, self.text = self.text[pos:pos + n], self.text[:pos] + self.text[pos + n:]
        return gone
@dataclass
class Insert:                                    # a request stored as an object
    doc: Document; pos: int; s: str
    def execute(self): self.doc.insert(self.pos, self.s)
    def undo(self): self.doc.delete(self.pos, len(self.s))
    def __str__(self): return f"Insert({self.pos},{self.s!r})"
@dataclass
class Delete:
    doc: Document; pos: int; n: int; gone: str = ""
    def execute(self): self.gone = self.doc.delete(self.pos, self.n)  # keep what was cut
    def undo(self): self.doc.insert(self.pos, self.gone)
    def __str__(self): return f"Delete({self.pos},{self.n})"
class Editor:                                    # invoker: runs commands, keeps history
    def __init__(self, doc): self.doc, self.undos, self.redos = doc, [], []
    def run(self, c): c.execute(); self.undos.append(c); self.redos.clear(); self.show(f"run {c}")
    def undo(self):
        if self.undos: c = self.undos.pop(); c.undo(); self.redos.append(c)
        self.show("undo")
    def redo(self):
        if self.redos: c = self.redos.pop(); c.execute(); self.undos.append(c)
        self.show("redo")
    def show(self, what): print(f"{what:20} text={self.doc.text!r:14} undo={len(self.undos)} redo={len(self.redos)}")
d = Document(); ed = Editor(d)
ed.run(Insert(d, 0, "Dhaka")); ed.run(Insert(d, 5, " city")); ed.run(Delete(d, 0, 2))
ed.undo(); ed.undo(); ed.redo(); ed.run(Insert(d, 10, "!")); ed.redo()
d2 = Document()                                  # replay the command log on a new document
for c in ed.undos: replace(c, doc=d2).execute()
print("replayed log:", [str(c) for c in ed.undos], "->", repr(d2.text))

run Insert(0,'Dhaka') text='Dhaka'        undo=1 redo=0
run Insert(5,' city') text='Dhaka city'   undo=2 redo=0
run Delete(0,2)      text='aka city'     undo=3 redo=0
undo                 text='Dhaka city'   undo=2 redo=1
undo                 text='Dhaka'        undo=1 redo=2
redo                 text='Dhaka city'   undo=2 redo=1
run Insert(10,'!')   text='Dhaka city!'  undo=3 redo=0
redo                 text='Dhaka city!'  undo=3 redo=0
replayed log: ["Insert(0,'Dhaka')", "Insert(5,' city')", "Insert(10,'!')"] -> 'Dhaka city!'

Queue, macro, log আর CQRS

• Queue: command যেহেতু একটি object, তাকে সারিতে রেখে পরে চালানো যায় — একটি job queue-র প্রতিটি job, বা “রাত ২টায় দাম হালনাগাদ” ধরনের কাজ। চালানোর সময় আর বানানোর সময় আলাদা হয়ে যায়।
• Macro: কয়েকটি command মিলিয়ে একটি command — macro command. এর execute() সবগুলোকে ক্রমে চালায়, undo() উল্টো ক্রমে উল্টায়। এক undo-তে পুরো “টেমপ্লেট বসাও” কাজ ফেরানো যায়। এটি পর্ব ৩৪-এর composite pattern-এর সাথে command-এর মিলন (Structural pattern).
• Log আর replay: অংশের কোডে দেখলেন। Database-এর write-ahead log বা একটি game-এর replay-ও একই চিন্তার বড় রূপ।
• CQRS-এর command: System Design-এর CQRS-এ “command” মানে অবস্থা বদলানোর অনুরোধ-বার্তা, যা একটি handler গ্রহণ করে — অনুরোধকে data বানানোর একই চিন্তা, কিন্তু এটি পুরো architecture-এর read আর write অংশ আলাদা করার নকশা (Event sourcing আর CQRS); আর এর নামের মূলে Meyer-এর command–query separation.

৬ · Template method — কাঠামো base class-এ, ধাপ subclass-এ

উদ্দেশ্য। GoF: একটি operation-এ algorithm-এর কঙ্কাল সংজ্ঞায়িত করুন, কিছু ধাপ subclass-এর ওপর ছেড়ে দিন; তাহলে subclass algorithm-এর কাঠামো না বদলে নির্দিষ্ট ধাপগুলো নতুন করে লিখতে পারে। Template method pattern-এ যে method কঙ্কালটি ধরে রাখে, সেটিই “template method”.

সমস্যা। বাজার অ্যাপের admin দিনের দামের report নামান — হিসাব বিভাগের জন্য CSV, ওয়েবসাইটে দেখানোর জন্য HTML. দুটির ধাপ একই: শিরোনাম, প্রতিটি পণ্যের সারি, কখনো মোট, শেষে পাদটীকা। দুটি আলাদা function লিখলে ক্রম আর loop দুই জায়গায় কপি হয়; কেউ একটিতে “খালি সারি বাদ দাও” যোগ করলে অন্যটিতে ভুলে যান।

কাঠামো। একটি abstract class-এ template method (export) ধাপগুলোর ক্রম ঠিক করে, আর ধাপগুলো তিন ধরনের: abstract ধাপ — subclass-কে লিখতেই হবে (header, row); ডিফল্টসহ ধাপ — চাইলে override করবে (footer); আর hook — একটি ফাঁকা বা ডিফল্ট উত্তরের method, যা দিয়ে subclass কাঠামোর একটি বিকল্প অংশ চালু-বন্ধ করে (wants_total). GoF নিজেই hook operation-এর কথা বলে, আর পরামর্শ দেয় কোনগুলো hook (override করা ঐচ্ছিক) আর কোনগুলো abstract (বাধ্যতামূলক) তা স্পষ্ট রাখতে।

নিচের stepper-এ HtmlExporter().export(ROWS) চলার সময় কে কাকে ডাকে, তা দেখুন। বাঁ দিকের কোড base class-এর template method-এর সরল রূপ; সবুজ দাগের লাইন এই ধাপে চলছে।

1class Exporter(ABC):2  def export(self, rows):3    out = [self.header()]4    out += [self.row(n, p) ...]5    if self.wants_total():6      out.append(self.row("TOTAL", ...))7    out.append(self.footer())8    return "\n".join(...)

একই কাজ, দুই পথে — template method আর strategy

নিচের কোডের ওপরের অর্ধেক stepper-এর template method; নিচের অর্ধেকে একই কাঠামো একটি সাধারণ function, আর বদলযোগ্য ধাপগুলো একটি Format object-এ — অর্থাৎ strategy. দুই পথের আউটপুট মেলানো হয়েছে।

from abc import ABC, abstractmethod
from dataclasses import dataclass, replace
ROWS = [("rice-5kg", 420), ("dal-1kg", 140)]
class Exporter(ABC):                     # TEMPLATE METHOD: skeleton in the base class
    def export(self, rows):              # the fixed order of steps (not overridden)
        out = [self.header()] + [self.row(n, p) for n, p in rows]
        if self.wants_total():           # hook: a default answer subclasses may change
            out.append(self.row("TOTAL", sum(p for _, p in rows)))
        return "\n".join(x for x in out + [self.footer()] if x)
    @abstractmethod
    def header(self): ...
    @abstractmethod
    def row(self, name, price): ...
    def footer(self): return ""          # optional step with a default
    def wants_total(self): return False  # the hook
class CsvExporter(Exporter):
    def header(self): return "item,price"
    def row(self, n, p): return f"{n},{p}"
class HtmlExporter(Exporter):
    def header(self): return "<table>"
    def row(self, n, p): return f"<tr><td>{n}</td><td>{p}</td></tr>"
    def footer(self): return "</table>"
    def wants_total(self): return True
@dataclass(frozen=True)                  # STRATEGY: the varying steps as one object
class Format:
    header: str; row: "Callable[[str, int], str]"; footer: str = ""; total: bool = False
def export(rows, f: Format):             # the same skeleton, written once, as a function
    out = [f.header] + [f.row(n, p) for n, p in rows]
    if f.total: out.append(f.row("TOTAL", sum(p for _, p in rows)))
    return "\n".join(x for x in out + [f.footer] if x)
CSV = Format("item,price", lambda n, p: f"{n},{p}")
HTML = Format("<table>", lambda n, p: f"<tr><td>{n}</td><td>{p}</td></tr>", "</table>", True)
print(CsvExporter().export(ROWS)); print(HtmlExporter().export(ROWS))
print("same:", export(ROWS, CSV) == CsvExporter().export(ROWS), export(ROWS, HTML) == HtmlExporter().export(ROWS))
print(export(ROWS, replace(CSV, total=True)))   # a new combination at runtime, no subclass

item,price
rice-5kg,420
dal-1kg,140
<table>
<tr><td>rice-5kg</td><td>420</td></tr>
<tr><td>dal-1kg</td><td>140</td></tr>
<tr><td>TOTAL</td><td>560</td></tr>
</table>
same: True True
item,price
rice-5kg,420
dal-1kg,140
TOTAL,560

ফলাফল আর ফাঁদ

• লাভ: ক্রম আর সাধারণ কোড এক জায়গায় (DRY); subclass ছোট থাকে; framework বানানোর সবচেয়ে সরল কৌশল।
• ফাঁদ ১ — fragile base class: subclass parent-এর ভেতরের ক্রমের ওপর নির্ভর করে। Parent-এর লেখক ধাপের ক্রম বা কোনো ধাপের ডাক বদলালে সব subclass চুপচাপ ভাঙতে পারে — একে বলে fragile base class সমস্যা।
• ফাঁদ ২ — template method override: subclass যদি পুরো export-ই নতুন করে লেখে, pattern-এর উদ্দেশ্য শেষ। Java-তে template method-কে final করা যায়; Python-এ নাম আর documentation দিয়ে জানাতে হয়।
• ফাঁদ ৩ — hook-এর অরণ্য: প্রতিটি নতুন অনুরোধে একটি hook যোগ করলে base class দশটি “চাইলে বদলান” method-এর জঙ্গল হয়, আর কোন hook কখন ডাকা হয় তা বুঝতে base class-এর পুরোটা পড়তে হয়।
• ফাঁদ ৪ — দুই অক্ষে বদল: format (CSV/HTML) আর উৎস (দাম/মজুদ) দুটোই বদলালে inheritance-এ ২ × ২ = ৪টি subclass, তিনটি অক্ষে আরও বেশি। Composition-এ প্রতিটি অক্ষ আলাদা strategy.

৭ · চারটি pattern পাশাপাশি — কখন কোনটি, কখন একটিও নয়

Template method আর strategy একই সমস্যার দুই উত্তর: algorithm-এর একটি অংশ বদলাতে হবে। Template method inheritance দিয়ে — বদলের অংশ subclass-এ, সিদ্ধান্ত class লেখার সময়। Strategy object composition দিয়ে — বদলের অংশ একটি আলাদা object-এ, সিদ্ধান্ত চলার সময়। GoF-এর শুরুর পরামর্শ — class inheritance-এর চেয়ে object composition পছন্দ করুন (composition over inheritance) — এই তুলনার পটভূমি; বিস্তারিত পর্ব ৩৭-এ (Dependency injection আর composition). তবু template method টিকে আছে, কারণ ধাপগুলো একে অপরের সাথে ঘনিষ্ঠ হলে (একই state ভাগ করে, একসাথে বদলায়) একটি subclass-এ রাখা অনেক সময় বেশি পরিষ্কার।

চারটি প্রায়ই একসাথে আসে। একটি বোতাম click হলে (observer) একটি command বানানো হয় (command), যা চালানোর সময় একটি বদলযোগ্য নিয়ম ব্যবহার করে (strategy), আর পুরো কাঠামো একটি framework-এর base class-এর template method মেনে চলে। Factory method (পর্ব ৩৩, Creational pattern) প্রায়ই একটি template method-এর একটি ধাপ — “কোন object বানাব” সিদ্ধান্তটি subclass-এ। আর GoF-এর একটি চমৎকার তুলনা: decorator (পর্ব ৩৪) object-এর “চামড়া” বদলায়, strategy বদলায় “ভেতরটা”।

কখন একটিও নয়

• নিয়ম একটি, বদলের ইতিহাস নেই — strategy নয়, একটি function (পর্ব ২৬-এর YAGNI; অপ্রয়োজনীয় নমনীয়তা হলো speculative generality).
• শ্রোতা একজন, আর সে কখনো বদলায় না — observer নয়, সরাসরি ডাক; প্রবাহ পড়া যায়।
• Undo, queue, log — কোনোটাই লাগে না — command class নয়, একটি method.
• দুটি “ধাপ”-ই মাত্র আলাদা — template method-এর বদলে একটি parameter বা ছোট function পাঠানো।

৮ · AI-এর যুগে — AI-এর লেখা pattern যাচাই

AI-কে “এখানে design pattern ব্যবহার করো” বললে প্রায় সবসময় কিছু একটা pattern আসবে — দরকার থাক বা না থাক। Pattern-এর নাম আর কাঠামো AI ভালোই জানে; দুর্বলতা আসে ফাঁদগুলোতে, যেগুলো কোড চালিয়ে না দেখলে ধরা পড়ে না।

AI-এর দেওয়া pattern হাতে পেলে — চেকলিস্ট

• প্রতিটি pattern-এর পক্ষে আজকের প্রমাণ আছে (একাধিক নিয়ম, একাধিক শ্রোতা, undo-র প্রয়োজন); না থাকলে সরল কোড রেখেছি
• প্রতিটি subscribe-এর পাশে তার unsubscribe খুঁজে পেয়েছি; খোলা-বন্ধ করে শ্রোতা গুনেছি
• একটি শ্রোতাকে ইচ্ছা করে error ছুড়তে দিয়ে দেখেছি বাকিরা খবর পায়, আর error হারায় না
• প্রতিটি command-এর execute-undo test আর undo-redo-নতুন command-redo ক্রম চালিয়েছি
• UML-এর তীর আর multiplicity নোটেশনের সাথে মিলিয়েছি; উদ্ধৃতি মূল বইয়ে মিলিয়েছি
• Diff পুরোটা একটি আলাদা branch-এ পড়েছি; কোডের license আর prompt-এর গোপনীয়তা দেখেছি