Creational pattern — singleton, factory method, abstract factory, builder আর prototype

১ · Object বানানো কেন আলাদা নকশার প্রশ্ন

একটি কাল্পনিক বাস-টিকিট অ্যাপ ধরুন। টিকিট কাটা হলে যাত্রীকে বার্তা যায়। প্রথম দিন কোডে লেখা হলো new SmsChannel(). কয়েক মাস পরে কিছু যাত্রী email চান, পরে app-এর push বার্তাও এলো। এখন যেখানে যেখানে new SmsChannel() লেখা, সব জায়গায় if বসাতে হবে। আর test-এর সময় আসল SMS gateway-তে বার্তা পাঠানো চলবে না — তখন নকল channel বসাতে হবে, কিন্তু কোডের গভীরে new বাঁধা থাকায় বসানোর জায়গা নেই।

সমস্যাটি এখানে: new SmsChannel() লেখা মানে কোডটি একটি নির্দিষ্ট class-এর নাম জানে। পর্ব ২৮-এর dependency inversion বলেছিল, উঁচু স্তরের কোড চুক্তির ওপর নির্ভর করবে, নির্দিষ্ট বাস্তবায়নের ওপর নয়। কিন্তু কাউকে না কাউকে তো আসল object বানাতেই হবে। Creational pattern সেই “কাউকে না কাউকে”-র নকশা — বানানোর দায় কোথায় থাকবে, কতবার বানানো হবে, আর কতটা বদলযোগ্য হবে।

Design pattern কী, pattern-এর বর্ণনার কাঠামো (নাম, উদ্দেশ্য, সমস্যা, কাঠামো, ফল) আর কখন pattern ব্যবহার করবেন না — এসব পর্ব ৩২-এ এসেছে। এখানে সরাসরি পাঁচটি pattern-এ যাব। ১৯৯৪ সালের Design Patterns: Elements of Reusable Object-Oriented Software বইয়ের চার লেখক — Erich Gamma, Richard Helm, Ralph Johnson আর John Vlissides, যাঁদের ডাকনাম Gang of Four (GoF) — ২৩টি pattern-কে তিন ভাগে ভাগ করেছিলেন। Creational ভাগে পাঁচটি:

২ · Singleton — একটিমাত্র instance, আর তার দাম

উদ্দেশ্য (GoF): একটি class-এর ঠিক একটি instance নিশ্চিত করা, আর সেটিতে পৌঁছানোর একটি বৈশ্বিক পথ দেওয়া। খেয়াল করুন, এখানে দুটি প্রতিশ্রুতি — “একটিই” আর “সবখান থেকে পাওয়া যায়”। Singleton-এর প্রায় সব সমস্যা দ্বিতীয়টি থেকে আসে।

সমস্যা: কিছু জিনিস সত্যিই একটি থাকা উচিত — একটি প্রক্রিয়ার configuration, একটি log লেখার ব্যবস্থা, একটি printer spooler. দুটি config object থাকলে একটিতে ভাষা “bn”, আরেকটিতে “en” — অদ্ভুত বাগ। কাঠামো: class-টি নিজের একটি static field-এ নিজের একমাত্র instance রাখে, constructor বাইরে থেকে ব্যবহার করতে দেয় না (Java-তে private), আর একটি static method (getInstance()) প্রথমবার instance বানায়, পরে প্রতিবার সেটিই ফেরত দেয়। UML-এ একটি class বাক্স: - instance: Config (নিচে দাগ, অর্থাৎ static), - Config(), + getInstance(): Config (নিচে দাগ) — পর্ব ২৯-এর static member-এর চিহ্ন।

নিচের Python কোডে তিনটি জিনিস: (১) __new__ দিয়ে ক্লাসিক Singleton — Python-এ Config() ডাকলে আগে __new__ চলে object বানাতে, তাই সেখানে একই object ফেরত দেওয়া যায়; (২) module-এর ভেতরে একটি instance — Python-এর স্বাভাবিক বিকল্প; (৩) একটি সতর্কবার্তা — দুটি test, যারা ক্রম বদলালেই ফল বদলায়।

import sys, threading, types

class Config:                          # way 1: __new__ hands back one object
    _instance = None
    _lock = threading.Lock()
    def __new__(cls):
        with cls._lock:                # makes check-then-create atomic
            if cls._instance is None:
                cls._instance = super().__new__(cls)
                cls._instance.settings = {"lang": "bn"}
        return cls._instance
a, b = Config(), Config()
a.settings["theme"] = "dark"
print("1) same object:", a is b, "| b sees:", b.settings)

# way 2: a module-level instance; this string plays the file appconfig.py
src = "class _Settings:\n    def __init__(self): self.values = {}\nsettings = _Settings()\n"
mod = types.ModuleType("appconfig"); exec(src, mod.__dict__)
sys.modules["appconfig"] = mod         # what the first real import does
import appconfig as m1
import appconfig as m2
print("2) cached module, same instance:", m1.settings is m2.settings)

# way 3 is a warning: hidden global state leaks between tests
def test_switch_to_english():
    Config().settings["lang"] = "en"; assert Config().settings["lang"] == "en"
def test_default_is_bangla():
    lang = Config().settings["lang"]; assert lang == "bn", f"got {lang!r}"
def run(*tests):
    for t in tests:
        try: t(); print("   PASS", t.__name__)
        except AssertionError as e: print("   FAIL", t.__name__, "-", e)
print("3) order A:"); run(test_default_is_bangla, test_switch_to_english)
Config._instance = None                # reset the hidden state
print("   order B:"); run(test_switch_to_english, test_default_is_bangla)

1) same object: True | b sees: {'lang': 'bn', 'theme': 'dark'}
2) cached module, same instance: True
3) order A:
   PASS test_default_is_bangla
   PASS test_switch_to_english
   order B:
   PASS test_switch_to_english
   FAIL test_default_is_bangla - got 'en'

Thread-safety আর lazy initialization — সংক্ষেপে

উপরের Config প্রথম দরকারের মুহূর্তে বানানো হয় — একে বলে lazy initialization. দুটি thread একই সময়ে প্রথমবার Config() ডাকলে দুজনই “এখনো কেউ নেই” দেখে দুটি instance বানাতে পারে — একটি race condition. তাই _lock: যাচাই আর বানানো একসাথে, একজনের পর একজন। প্রতিবার lock নেওয়ার খরচ এড়াতে কেউ কেউ lock-এর বাইরে একবার আর ভেতরে আরেকবার যাচাই করেন — double-checked locking. Java-তে এই কৌশল Java 5-এর আগে নির্ভরযোগ্য ছিল না; এখন field-টি volatile হলে কাজ করে (ভাবনার প্রশ্ন ৩-এ বিস্তারিত)। Thread-safety-র সবচেয়ে সহজ পথ প্রায়ই lazy না হওয়া: প্রোগ্রাম শুরুর সময় একবার বানিয়ে ফেলা। Python-এ module import নিজেই একটি import lock-এর ভেতরে হয়, তাই module-স্তরের instance সাধারণত একবারই তৈরি হয়।

কেন Singleton প্রায়ই anti-pattern

• লুকানো dependency: OrderService-এর constructor দেখে বোঝা যায় না যে ভেতরে Config.getInstance() ডাকা হয়। Function-এর signature মিথ্যা বলে; নির্ভরতা লুকিয়ে থাকে। এটি আসলে একটি সুন্দর নাম দেওয়া global variable — পর্ব ২৫-এর common coupling.
• Test-এর কষ্ট: উপরে দেখলেন — global state এক test থেকে আরেকটিতে চুইয়ে পড়ে, test isolation ভাঙে। আর নকল config বা test double বসাতে হলে singleton-এর ভেতরে হাত দিতে হয়।
• “একটিই” অনুমান ভাঙে: আজ একটি database; কাল একটি read replica এলো, বা একই প্রক্রিয়ায় দুটি tenant-এর আলাদা config লাগল। Class নিজেই “আমি একটি” ঘোষণা করে রাখলে বদল কঠিন।
• দুই দায় এক class-এ: নিজের কাজ আর “কতগুলো আমি থাকব” — পর্ব ২৭-এর SRP-র চোখে দুটি আলাদা পরিবর্তনের কারণ।

Python আর JavaScript-এর idiom: Python-এ config.py ফাইলে settings = Settings() লিখলেই যথেষ্ট; ES module-এও তাই — export const settings = new Settings(); লেখা module প্রথম import-এ একবার চলে, আর module map সবাইকে একই object দেয়। এগুলো GoF-এর কাঠামো ছাড়াই “একটিমাত্র” দেয়, তবে global access-এর সমস্যা পুরো যায় না — যেখানে সম্ভব, তবু parameter দিয়ে দিন। বিস্তারিত দেখুন Python-এর module আর JavaScript-এর ES module পর্বে।

বাস্তবে: Python-এর None, True, False ভাষার স্তরে singleton — x is None লেখা যায় এজন্যই। logging.getLogger("app") একই নামে সবসময় একই logger ফেরত দেয় — নাম ধরে একটি করে instance, যাকে কেউ কেউ “multiton” বা registry বলেন। Java-র Runtime.getRuntime() প্রায়ই ক্লাসিক GoF singleton-এর উদাহরণ হিসেবে বলা হয়।

৩ · Factory Method — কোন product, ঠিক করে subclass

উদ্দেশ্য (GoF): object বানানোর জন্য একটি interface ঘোষণা করা, কিন্তু কোন class-এর object হবে তা subclass-কে ঠিক করতে দেওয়া। GoF এর আরেক নাম দিয়েছিল “virtual constructor”. সমস্যা: একটি base class-এর একটি কাজ আছে, যার ভেতরে একটি product object লাগে — যেমন Notifier.notify()-এর ভেতরে একটি channel. কাজের ধাপগুলো সব subclass-এ এক, শুধু product আলাদা। Base class-এ new SmsChannel() লিখলে email-এর subclass কিছু করতে পারে না; প্রতিটি subclass-এ পুরো notify() কপি করলে duplication.

সমাধান: base class-এ একটি আলাদা method — createChannel() — যাকে বলে factory method. notify() সেটিকে ডাকে, কিন্তু নিজে কোনো concrete class-এর নাম জানে না। প্রতিটি subclass শুধু createChannel() override করে নিজের product ফেরত দেয়। এটি polymorphism দিয়ে বানানোর সিদ্ধান্ত পিছিয়ে দেওয়া; আর পর্ব ৩৫-এর template method pattern-এর খুব কাছের আত্মীয় — notify() একটি ছাঁচ, যার একটি ধাপ subclass পূরণ করে।

ছবিতে চারটি ভূমিকা, GoF-এর নামে: Creator (Notifier — abstract class), ConcreteCreator (SmsNotifier — inheritance দিয়ে), Product (Channel — interface) আর ConcreteProduct (SmsChannel — realization). তীরগুলো পর্ব ২৯-এর নিয়মে আঁকা: generalization-এ ত্রিভুজ সাধারণটির দিকে, আর dependency-তে খোলা তীর যাকে ব্যবহার করা হয় তার দিকে। Factory Method আর Abstract Factory দুটির কোডই চালানো যায় এমনভাবে পরের অংশে একসাথে আছে।

নামের গোলমাল: simple factory আর static factory method

সবচেয়ে প্রচলিত “factory” আসলে Factory Method নয়। একটি function, যা parameter দেখে ঠিক object বানায় — makeChannel("sms") — তাকে বলে simple factory. এটি খুব কাজের, কিন্তু GoF-এর ২৩টি pattern-এর একটি নয়; এতে কোনো subclass বা override নেই, আছে একটি সিদ্ধান্তের জায়গা (প্রায়ই একটি switch বা একটি dictionary-র registry). Python-এ datetime.fromtimestamp(...) বা Java-র List.of(...)-এর মতো নাম দেওয়া বিকল্প constructor-কে বলে static factory method — Joshua Bloch-এর Effective Java-র প্রথম পরামর্শই এটি, আর Bloch নিজেই লিখেছেন যে এটি GoF-এর Factory Method-এর সমান নয়। পরীক্ষা বা ইন্টারভিউতে “factory pattern” বললে প্রশ্নকর্তা কোনটি বোঝাচ্ছেন, জিজ্ঞেস করে নেওয়া বুদ্ধিমানের কাজ।

ফল: (+) ব্যবহারকারী কোড concrete class থেকে মুক্ত, নতুন product মানে নতুন subclass — পর্ব ২৭-এর open-closed. (+) Subclass-কে একটি “hook” দেয়, যেখানে বানানোর খুঁটিনাটি বদলানো যায়। (−) শুধু একটি object বানানোর জন্য নতুন একটি subclass লাগে; প্রতিটি product-এর জন্য creator-এর একটি জোড়া — class-এর সংখ্যা বাড়ে। ফাঁদ: constructor-এর ভেতর থেকে factory method ডাকবেন না — Java বা C#-এ তখন subclass-এর field তৈরি হওয়ার আগেই override-করা method চলে। আর যেখানে শুধু parameter দেখে বাছাই দরকার, সেখানে subclass-এর পুরো শ্রেণিবিন্যাস বানানো over-engineering; একটি simple factory বা function-এর parameter হিসেবে class পাঠানোই যথেষ্ট।

বাস্তবে: Java-র Collection.iterator() প্রায়ই ক্লাসিক উদাহরণ — প্রতিটি collection class নিজের রকমের iterator বানায়, আর ব্যবহারকারী শুধু Iterator চুক্তি চেনে। Python-এর __iter__-ও একই ভাবনার: for লুপ জানে না কোন iterator আসবে, object নিজে ঠিক করে।

৪ · Abstract Factory — মিলে যাওয়া পুরো পরিবার

উদ্দেশ্য (GoF): সম্পর্কিত বা পরস্পরনির্ভর কয়েকটি object-এর পরিবার বানানোর একটি interface দেওয়া, তাদের concrete class উল্লেখ না করে। সমস্যা: বাস-টিকিট অ্যাপের বার্তায় এখন তিনটি অংশ — বার্তার লেখা (message), ঠিকানা (address) আর পাঠানোর যন্ত্র (sender). SMS-এর লেখা ছোট আর সাদা, ঠিকানা ফোন নম্বর, পাঠায় SMS gateway; email-এর লেখা HTML, ঠিকানা email, পাঠায় mail server. এগুলো একটি product family. কেউ ভুল করে SMS sender-এ email ঠিকানা দিলে — gateway “rahim@example.com” নম্বরে SMS পাঠানোর চেষ্টা করবে। মেশানো অবস্থাটিই বাগ।

সমাধান: একটি interface NotificationKit, যার তিনটি method: createMessage, createAddress, createSender. প্রতিটি পরিবারের জন্য একটি concrete kit — SmsKit, EmailKit — যা নিজের পরিবারের তিনটিই বানায়। ব্যবহারকারী কোড একটি kit হাতে পায় আর তা থেকেই সব নেয়, তাই পরিবার মেশানো অসম্ভব হয়ে যায়। কোন kit, সেটি প্রোগ্রামের শুরুতে একবার ঠিক হয়। খেয়াল করুন, Abstract Factory-র প্রতিটি createX method নিজেই প্রায়ই একটি factory method — GoF-ও তা বলেছে।

এবার stepper-এ দেখুন, একটি kit কীভাবে একটি সামঞ্জস্যপূর্ণ পরিবার বানায়, আর configuration-এর একটি শব্দ বদলালে পুরো পরিবার একসাথে কীভাবে বদলে যায়।

নিচের JavaScript কোডে আগে Factory Method (অংশ ৩-এর ছবির মতো), তারপর একই অ্যাপের Abstract Factory. প্রতিটি তৈরি product-এর class-এর নাম ছাপা হয়েছে, যাতে দেখা যায় কোন object আসলে তৈরি হলো। (সব নাম, নম্বর আর ঠিকানা কাল্পনিক।)

// Fictional bus-ticket app: a notification kit (all names invented)
// --- Factory Method: a subclass decides which channel object to create
class Notifier {
  createChannel() { throw new Error("subclass must override"); }
  notify(to, text) {                    // uses the product, never names its class
    const ch = this.createChannel();
    return `${ch.constructor.name} -> ${ch.deliver(to, text)}`;
  }
}
class SmsChannel   { deliver(to, t) { return `sms ${to}: ${t.slice(0, 18)}...`; } }
class EmailChannel { deliver(to, t) { return `mail ${to}: ${t}`; } }
class SmsNotifier   extends Notifier { createChannel() { return new SmsChannel(); } }
class EmailNotifier extends Notifier { createChannel() { return new EmailChannel(); } }
for (const n of [new SmsNotifier(), new EmailNotifier()])
  console.log(n.notify("rahim", "Seat A3 confirmed, bus leaves 07:30"));

// --- Abstract Factory: one kit creates a whole matching family
class SmsMessage  { constructor(t) { this.body = t.slice(0, 18); } }
class SmsAddress  { constructor(u) { this.value = u.phone; } }
class SmsSender   { send(a, m) { return `[gateway] ${a.value} <- ${m.body}`; } }
class EmailMessage { constructor(t) { this.body = `<p>${t}</p>`; } }
class EmailAddress { constructor(u) { this.value = u.email; } }
class EmailSender  { send(a, m) { return `[smtp] ${a.value} <- ${m.body}`; } }
const SmsKit = { createMessage: t => new SmsMessage(t),
  createAddress: u => new SmsAddress(u), createSender: () => new SmsSender() };
const EmailKit = { createMessage: t => new EmailMessage(t),
  createAddress: u => new EmailAddress(u), createSender: () => new EmailSender() };

function sendTicket(kit, user, text) {   // client knows only the kit's methods
  const m = kit.createMessage(text), a = kit.createAddress(user), s = kit.createSender();
  console.log([m, a, s].map(p => p.constructor.name).join(" + "));
  console.log("   " + s.send(a, m));
}
const user = { phone: "01700-000000", email: "rahim@example.com" };
for (const kit of [SmsKit, EmailKit]) sendTicket(kit, user, "Seat A3 confirmed, bus leaves 07:30");

SmsChannel -> sms rahim: Seat A3 confirmed,...
EmailChannel -> mail rahim: Seat A3 confirmed, bus leaves 07:30
SmsMessage + SmsAddress + SmsSender
   [gateway] 01700-000000 <- Seat A3 confirmed,
EmailMessage + EmailAddress + EmailSender
   [smtp] rahim@example.com <- <p>Seat A3 confirmed, bus leaves 07:30</p>

ফল, ফাঁদ আর বাস্তব উদাহরণ

(+) পরিবারের সামঞ্জস্য নিশ্চিত, concrete class ব্যবহারকারী কোড থেকে লুকানো, আর পুরো পরিবার বদলানো এক জায়গার কাজ। (+) নতুন পরিবার যোগ করা সহজ: PushKit আর তার তিনটি product — নতুন ফাইল, পুরোনো কোড অপরিবর্তিত। (−) নতুন ধরনের product যোগ করা কঠিন: ধরুন প্রতিটি বার্তার সাথে একটি “template” object লাগবে। তখন NotificationKit interface-এ নতুন method, আর প্রতিটি concrete kit বদলাতে হবে — তিন পরিবার থাকলে তিনটিই। এটি একটি পুরোনো টানাপোড়েনের রূপ, যাকে বলে expression problem: একটি নকশা হয় নতুন ধরন সহজ করে, নয়তো নতুন operation; দুটি একসাথে সহজ হয় না (ভাবনার প্রশ্ন ৫)।

ফাঁদ: পরিবার আসলে না থাকলে — অর্থাৎ product-গুলো একে অপরের সাথে বাঁধা না হলে — Abstract Factory অকারণ স্তর। দুটি UI theme-এর মধ্যে শুধু রঙ আলাদা হলে একটি theme object-এ কয়েকটি মান রাখাই যথেষ্ট; button-এর আচরণ আর menu-র আচরণ যখন theme-ভেদে একসাথে বদলায়, তখনই kit-এর দাম ওঠে। বাস্তবে: UI toolkit-এর “look and feel” (একই প্রোগ্রাম Windows-ধাঁচ বা অন্য ধাঁচের button, scrollbar, menu একসাথে পায়) আর কোনো payment provider-এর SDK-র kit (একই provider-এর payment, refund, webhook যাচাইয়ের object) এর প্রচলিত উদাহরণ। Java-র DocumentBuilderFactory-কেও অনেক বইয়ে Abstract Factory-র উদাহরণ বলা হয়, যদিও এর নকশা খুঁটিনাটিতে pure GoF রূপ নয়।

৫ · Builder — ধাপে ধাপে বানানো, শেষে যাচাই

উদ্দেশ্য (GoF): একটি জটিল object-এর বানানোর প্রক্রিয়াকে তার রূপ থেকে আলাদা করা, যাতে একই প্রক্রিয়া থেকে ভিন্ন রূপ বানানো যায়। আজকের ব্যবহারে Builder-এর সবচেয়ে প্রচলিত রূপটি একটু ভিন্ন, যাকে Bloch-এর Effective Java জনপ্রিয় করেছে: অনেক parameter-এর object ধাপে ধাপে জোড়া, আর শেষে একটি build() সব নিয়ম যাচাই করে সম্পূর্ণ, প্রায়ই immutable object দেয়।

সমস্যা — telescoping constructor: একটি টিকিটে route, তারিখ, আসন, যাত্রী, ভাড়া আবশ্যক; খাবার, বিমা ঐচ্ছিক। Java-র মতো ভাষায় এর জন্য একটির পর একটি constructor: ৫টি parameter-এর, ৬টির, ৭টির — দূরবীনের নল যেমন একটির ভেতর থেকে আরেকটি বেরোয়, তাই নাম telescoping constructor. ডাকার জায়গায় দেখা যায় new Ticket("DHK-CTG", "2026-12-14", "A3", "Rahim", 950, false, true) — শেষের দুটি boolean-এর কোনটি খাবার আর কোনটি বিমা, পড়ে বোঝার উপায় নেই। উল্টে গেলেও compiler কিছু বলে না, কারণ দুটির type একই।

কাঠামো: একটি TicketBuilder class, যার প্রতিটি method একটি অংশ বসিয়ে নিজেকেই ফেরত দেয় (return self), তাই কলগুলো শিকলের মতো লেখা যায় — fluent interface. শেষে build(). GoF-এর মূল রূপে আরও একটি ঐচ্ছিক অংশ আছে — Director, যে একটি ঠিক করা ক্রমে builder-এর ধাপগুলো ডাকে (যেমন “ঈদের বিশেষ বাস” টিকিটের একটি তৈরি রেসিপি)। আর GoF-এ একই director ভিন্ন builder পেলে ভিন্ন রূপ বানায় — একই নথি থেকে একটি builder HTML, আরেকটি সাদা লেখা। আধুনিক fluent builder-এ director প্রায়ই থাকে না; client নিজেই director.

1b = TicketBuilder()2b.route("DHK-CTG").on("2026-12-14")3b.passenger("Rahim")4b.build()          # too early?5b.seat("A3").fare(950)6b.with_meal()7t = b.build()

এবার পুরো কোডটি চালিয়ে দেখুন। প্রথমে positional ডাকের সেই নিঃশব্দ ভুল, তারপর builder, তারপর ভাড়া শূন্য দিলে build()-এর আপত্তি।

from dataclasses import dataclass

@dataclass(frozen=True)
class Ticket:
    route: str; date: str; seat: str; passenger: str
    fare: int; meal: bool = False; insurance: bool = False

# Telescoping style: a long positional list. Which True is which?
t1 = Ticket("DHK-CTG", "2026-12-14", "A3", "Rahim", 950, False, True)
print("positional:", t1.meal, t1.insurance, "(meant meal=True!)")

class TicketBuilder:
    REQUIRED = ("route", "date", "seat", "passenger", "fare")
    def __init__(self): self._d = {}
    def route(self, r): self._d["route"] = r; return self
    def on(self, d): self._d["date"] = d; return self
    def seat(self, s): self._d["seat"] = s; return self
    def passenger(self, p): self._d["passenger"] = p; return self
    def fare(self, taka): self._d["fare"] = taka; return self
    def with_meal(self): self._d["meal"] = True; return self
    def build(self):                     # every rule checked in one place
        missing = [k for k in self.REQUIRED if k not in self._d]
        if missing: raise ValueError("missing " + ", ".join(missing))
        if self._d["fare"] <= 0: raise ValueError("fare must be positive")
        return Ticket(**self._d)

b = TicketBuilder().route("DHK-CTG").on("2026-12-14").passenger("Rahim")
try: b.build()
except ValueError as e: print("build() refused:", e)
t2 = b.seat("A3").fare(950).with_meal().build()
print("builder:", t2)
try: TicketBuilder().route("DHK-CTG").on("2026-12-14").seat("B1") \
        .passenger("Karim").fare(0).build()
except ValueError as e: print("build() refused:", e)

positional: False True (meant meal=True!)
build() refused: missing seat, fare
builder: Ticket(route='DHK-CTG', date='2026-12-14', seat='A3', passenger='Rahim', fare=950, meal=True, insurance=False)
build() refused: fare must be positive

ফল: (+) পড়তে সহজ ডাক, ঐচ্ছিক অংশের যেকোনো মিশ্রণ, এক জায়গায় যাচাই, আর immutable ফল। (−) প্রতিটি field দুবার লেখা — একবার object-এ, একবার builder-এ; field যোগ করলে দুটি জায়গা বদলাতে হয়। ফাঁদ: build()-এ যাচাই না রাখলে builder শুধু লম্বা লেখা constructor; একই builder থেকে দুবার build() করলে দুটি object যেন ভেতরের mutable list ভাগ না করে, সেটি দেখুন। বাস্তবে: Java 11-এর HttpRequest.newBuilder() একটি পরিষ্কার fluent builder; Java-র Lombok library-র @Builder annotation নিজেই builder class লিখে দেয়; অনেক ভাষার SQL query builder library-ও এই ধাঁচের। StringBuilder-কেও প্রায়ই builder বলা হয়, যদিও সেটি মূলত একটি পরিবর্তনযোগ্য string-এর buffer — নামের মিল, pattern-এর পুরো রূপ নয়।

৬ · Prototype — কপি করে বানানো, আর shallow copy-র ফাঁদ

উদ্দেশ্য (GoF): একটি নমুনা instance দিয়ে কোন ধরনের object বানাতে হবে তা বোঝানো, আর সেই নমুনা কপি করে নতুন object বানানো। সমস্যা: কিছু object বানাতে খরচ বেশি বা ধাপ অনেক — যেমন একটি বাস রুটের template: route, ভাড়া, থামার জায়গার তালিকা, আসনের নকশা, ডেটাবেস থেকে পড়া নিয়ম। প্রতিদিনের প্রতিটি যাত্রার জন্য সব নতুন করে বানানোর চেয়ে একটি তৈরি template কপি করে শুধু তারিখ আর সময় বদলানো সহজ। আরেক সুবিধা: কপি করার কোড জানতেই হয় না object-টি কোন class-এর — prototype.clone() ডাকলেই হলো।

কাঠামো: একটি interface-এ clone() method; প্রতিটি concrete class নিজের কপি বানাতে জানে। প্রায়ই একটি prototype registry থাকে: নাম থেকে নমুনা — "DHK-CTG" চাইলে সেই template-এর কপি। Prototype-এর আসল কঠিন প্রশ্ন একটিই: কপি কতটা গভীর হবে?

নিচের কোডটি stepper-এর গল্পই চালায়, আর শেষে একটি দ্বিতীয় ফাঁদ দেখায়: structuredClone class চেনে না।

// Prototype: new trips are cloned from a ready-made template (fictional)
const template = { route: "DHK-CTG", fare: 950,
                   stops: ["Dhaka", "Cumilla", "Chattogram"] };

const shallow = { ...template };           // copies the top level only
shallow.fare = 1100;                       // a number: copied by value
shallow.stops.push("Feni");                // an array: still the SAME array
console.log("template.fare :", template.fare);
console.log("template.stops:", template.stops.join(" > "));
console.log("same array?   :", shallow.stops === template.stops);

template.stops.pop();                      // undo the damage
const deep = structuredClone(template);    // copies nested data too
deep.stops.push("Feni");
console.log("after deep    :", template.stops.length, "vs", deep.stops.length);

class Trip {                               // a pitfall of structuredClone
  constructor(route, stops) { this.route = route; this.stops = stops; }
  label() { return `${this.route} (${this.stops.length} stops)`; }
  clone() { return new Trip(this.route, [...this.stops]); } // Prototype's clone()
}
const t = new Trip("DHK-SYL", ["Dhaka", "Bhairab", "Sylhet"]);
const plain = structuredClone(t);
console.log("structuredClone keeps class?", plain instanceof Trip);
const c = t.clone(); c.stops.push("Moulvibazar");
console.log("clone():", c.label(), "| original:", t.label());

template.fare : 950
template.stops: Dhaka > Cumilla > Chattogram > Feni
same array?   : true
after deep    : 3 vs 4
structuredClone keeps class? false
clone(): DHK-SYL (4 stops) | original: DHK-SYL (3 stops)

Python-এ copy আর deepcopy

Python-এর copy module-এ দুটি function: copy.copy(x) shallow, copy.deepcopy(x) deep. Class চাইলে __copy__ আর __deepcopy__ লিখে নিজের নিয়ম দিতে পারে — Python-এ Prototype-এর clone() এটিই। deepcopy একটি memo dictionary রাখে, তাই নিজের দিকে ফিরে আসা (cyclic) গঠনেও আটকে যায় না। কিন্তু lock, খোলা file বা network connection-এর মতো object অর্থপূর্ণভাবে কপি করা যায় না — deepcopy হয় error দেবে, নয়তো এমন কিছু কপি করবে যা আপনি চাননি। List-এর list(x), x[:], dict.copy() — সবই shallow. বিস্তারিত দেখুন Python-এর mutability ও copying পর্বে; JavaScript-এর spread আর prototype-এর জন্য destructuring ও spread আর prototype পর্ব।

ফল: (+) concrete class না জেনে নতুন object, দামি প্রস্তুতি একবারই, আর চলার সময় নতুন “ধরন” যোগ (একটি নতুন নমুনা registry-তে রাখা)। (−) প্রতিটি class-এ ঠিক clone() লেখা কঠিন, বিশেষ করে ভেতরে ভাগ করা আর নিজস্ব অংশ মেশানো থাকলে। ফাঁদ: shallow copy-র ভাগ হওয়া অংশ; deep copy-র খরচ আর অ-কপিযোগ্য অংশ; আর Java-র Object.clone()/Cloneable — Bloch এটিকে নকশায় ত্রুটিপূর্ণ বলেছেন আর copy constructor বা copy factory-র পরামর্শ দিয়েছেন। সবচেয়ে পরিষ্কার বিকল্প প্রায়ই immutable data: যা বদলায় না, তা ভাগ করা নিরাপদ, কপির প্রশ্নই ওঠে না (পর্ব ৩১-এর value object আর defensive copy). নামের মিল: JavaScript-এর “prototype-ভিত্তিক inheritance” (Object.create(proto)) একটি ভাষার বৈশিষ্ট্য — নতুন object একটি পুরোনো object-কে ভিত্তি করে, কপি না করে। ধারণা কাছাকাছি, কিন্তু GoF-এর Prototype pattern-এর সমান নয়।

৭ · Object pool, তুলনা আর কোনটি কখন

Object pool — সংক্ষেপে (GoF-এর বাইরে)

কিছু object বানাতে সময় আর সম্পদ — দুটোই খরচ হয়: database connection (network handshake, login), thread, বড় buffer. Object pool এগুলোর কয়েকটি আগে থেকে বানিয়ে রাখে; কাজের সময় একটি ধার নেওয়া হয়, কাজ শেষে ফেরত — নতুন বানানো বা ধ্বংস নয়। বাস টার্মিনালের কাউন্টারে ভাড়ার ছাতার মতো: সংখ্যা সীমিত, নিয়ে ফেরত দিতে হয়। এটি GoF-এর ২৩টির মধ্যে নেই, তবে বাস্তবে খুব প্রচলিত — Java-র HikariCP-র মতো connection pool, SQLAlchemy-র ভেতরের pool, Python-এর concurrent.futures.ThreadPoolExecutor. ফাঁদ: ফেরত দিতে ভুললে pool খালি হয়ে সবাই অপেক্ষায় আটকায় (তাই Python-এ with); ফেরত দেওয়ার আগে অবস্থা পরিষ্কার না করলে পরের ব্যবহারকারী আগের জনের data পায়; আর সস্তা object pool করলে লাভের চেয়ে জটিলতা বেশি — আধুনিক garbage collector-এ ছোট object বানানো খুব সস্তা।

তুলনার টেবিল

বাছাইয়ের সহজ নির্দেশিকা

1. আগে জিজ্ঞেস করুন: সাধারণ constructor কি যথেষ্ট? একটি জায়গায় Ticket(...) ডাকলে কোনো pattern লাগে না। Pattern আনুন ব্যথা দেখা দিলে — একই if kind == ... তিন জায়গায়, বা test-এ নকল বসানোর জায়গা নেই (পর্ব ২৬-এর YAGNI আর rule of three).
2. “কোন class” প্রশ্ন একটি product নিয়ে? Input দেখে বাছাই → simple factory বা registry. Subclass-এর কাজের ভেতরে product বদলায় → Factory Method.
3. কয়েকটি product একসাথে বদলায়? Abstract Factory — কিন্তু আগে দেখুন, নতুন product-এর ধরন ঘনঘন আসবে কি না।
4. সমস্যা “কীভাবে জোড়া” — অনেক অংশ, নিয়ম, ক্রম? Builder; Python-এ আগে keyword argument আর dataclass চেষ্টা করুন।
5. তৈরি নমুনা থেকে কপি? Prototype — আর প্রথমেই ঠিক করুন কোন অংশ shallow চলবে, কোনটি deep হতেই হবে।
6. “একটিই থাকবে” মনে হচ্ছে? একটি বানান, inject করুন। Class-কে নিজে নিজের সংখ্যা পাহারা দিতে দেবেন না, যদি না সত্যিই উপায় না থাকে।

৮ · AI-এর যুগে creational pattern

“একটি notification system design করে দিন” বললে AI প্রায়ই একসাথে একটি NotificationFactory, একটি NotificationManager singleton, একটি NotificationBuilder আর তিন স্তরের interface নিয়ে আসে। কোডটি “পেশাদার” দেখায়, কিন্তু একটি ছোট অ্যাপে এর অর্ধেকই অকারণ। AI pattern-এর নাম আর আকার ভালো জানে; আপনার project-এর আকার, পরিবর্তনের ইতিহাস আর test-এর চাহিদা জানে না। তাই AI-এর প্রস্তাবে প্রথম প্রশ্ন সবসময়: “এই স্তর না থাকলে কী ক্ষতি হতো?”

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

• প্রতিটি pattern-এর জন্য বলতে পারি কোন বাস্তব ব্যথা এটি সারাচ্ছে — শুধু “ভবিষ্যতে লাগতে পারে” নয়
• Singleton থাকলে test-গুলো এলোমেলো ক্রমে চালিয়ে দেখেছি (যেমন pytest-এর random-order plugin বা হাতে ক্রম বদলে)
• Builder-এর build() অসম্পূর্ণ বা অবৈধ ইনপুট প্রত্যাখ্যান করে — সেটির test আছে
• “Clone”-এর পরে কপির ভেতরের list বা object বদলে আসলটি অপরিবর্তিত কি না দেখেছি
• AI-এর আঁকা UML-এর প্রতিটি তীর আর চিহ্ন নিজে মিলিয়েছি, আর library-র দাবি অফিসিয়াল documentation-এ দেখেছি
• AI-কে কোড দেওয়ার আগে config থেকে আসল API key, password বা যাত্রীর তথ্য সরিয়েছি