Structural pattern — adapter, decorator, facade, proxy আর composite

১ · Structural pattern কী — জিনিস জোড়া লাগানোর নকশা

পর্ব ৩৩-এ (Creational pattern) দেখেছেন object কীভাবে তৈরি হয়। এবার প্রশ্ন: তৈরি হওয়া object-গুলো কীভাবে জোড়া লাগে? একটি বাড়ির কথা ভাবুন। ইট, রড, পাইপ, বৈদ্যুতিক তার — সব আলাদাভাবে ভালো মানের হলেও জোড়ার জায়গাগুলো ভুল হলে বাড়ি টেকে না। প্লাম্বার জানেন কোন মাপের পাইপের সাথে কোন মাপের জোড়া (fitting) লাগে; ইলেকট্রিশিয়ান জানেন এক বোর্ড থেকে কয়টি লাইন টানা নিরাপদ। Structural pattern হলো সফটওয়্যারের এই জোড়ার নকশা।

১৯৯৪ সালের Gang of Four (GoF) বই Design Patterns-এ ২৩টি design pattern তিন শ্রেণিতে ভাগ করা: ৫টি creational, ৭টি structural আর ১১টি behavioral. Structural সাতটি হলো Adapter, Bridge, Composite, Decorator, Facade, Flyweight আর Proxy. Pattern-এর সাধারণ ভাষা — নাম, উদ্দেশ্য, প্রয়োগক্ষেত্র, ফলাফল — পর্ব ৩২-এ (Design pattern কী) এসেছে; এখানে সরাসরি সাতটির ভেতরে ঢুকব।

GoF আরও একটি ভাগ করে: class স্তরের pattern inheritance দিয়ে compile-এর সময়েই সম্পর্ক বাঁধে, আর object স্তরের pattern composition দিয়ে চলার সময় সম্পর্ক গড়ে। সাতটির মধ্যে শুধু Adapter-এর দুই রূপই আছে — class adapter আর object adapter; বাকি ছয়টি object স্তরের। এজন্যই structural pattern বোঝার আগে পর্ব ২৯-এর UML class diagram-এর তিনটি তীর চোখে পরিষ্কার থাকা দরকার: ফাঁপা ত্রিভুজসহ ড্যাশ রেখা (realization, interface মানা), ফাঁপা ত্রিভুজসহ টানা রেখা (generalization, inheritance) আর খোলা তীরের association (ধরে রাখা)।

২ · Adapter — অমিল interface মিলিয়ে দেওয়া

উদ্দেশ্য (GoF-এর ভাষায়, সংক্ষেপে): একটি class-এর interface-কে client-এর প্রত্যাশিত আরেকটি interface-এ রূপান্তর করা, যাতে অমিল interface-এর কারণে যারা একসাথে কাজ করতে পারত না, তারা পারে। Adapter-এর আরেক নাম wrapper.

সমস্যা — দুটি payment gateway, দুই রকম ভাষা

একটি কাল্পনিক অনলাইন বাজার অ্যাপের checkout কোড চায় খুব সহজ একটি চুক্তি: pay(amount) ডাকুন, ফেরত পান { ok, id }. কিন্তু দুটি কাল্পনিক gateway-এর SDK এই ভাষায় কথা বলে না:

• TakaPay: টাকা নয়, পয়সায় পরিমাণ চায়, একটি reference-সহ object-এ: makePayment({ paisa, ref }). ফেরত দেয় { status: "OK", txn }.
• DeshCard: দুই ধাপে কাজ করে — আগে authorize("349.50") (পরিমাণ string-এ), তারপর capture(authId). সফল হলে code হয় 0.

SDK-র কোড আপনার নয়, বদলাতে পারবেন না; আর checkout-এর ভেতরে if (gateway === "takapay") … else … লিখলে পর্ব ২৭-এর open-closed principle ভাঙবে — প্রতিটি নতুন gateway-তে checkout বদলাতে হবে। এখানে যিনি মানিয়ে নেওয়া হচ্ছেন, সেই SDK হলো adaptee; আপনার চুক্তি pay(amount) হলো target.

কাঠামো আর কোড

প্রতিটি SDK-র জন্য একটি ছোট adapter class, যা target চুক্তি মানে আর ভেতরে SDK-র একটি object ধরে রাখে। Checkout শুধু target-কে চেনে:

// Two fictional payment SDKs with different APIs (we cannot change them)
class TakaPaySdk {                       // wants paisa and a reference
  makePayment(req) { return { status: "OK", txn: "TP-" + (1000 + req.paisa / 100) }; }
}
class DeshCardSdk {                      // two steps: authorize, then capture
  authorize(amountStr) { return "AUTH-" + amountStr.replace(".", ""); }
  capture(authId) { return { code: 0, ref: authId.replace("AUTH", "DC") }; }
}

// Our interface: pay(amount) -> { ok, id }
class TakaPayAdapter {
  constructor(sdk) { this.sdk = sdk; }   // object adapter: holds the adaptee
  pay(amount) {
    const r = this.sdk.makePayment({ paisa: Math.round(amount * 100), ref: "ORD" });
    return { ok: r.status === "OK", id: r.txn };
  }
}
class DeshCardAdapter {
  constructor(sdk) { this.sdk = sdk; }
  pay(amount) {
    const auth = this.sdk.authorize(amount.toFixed(2));
    const r = this.sdk.capture(auth);
    return { ok: r.code === 0, id: r.ref };
  }
}

// Checkout knows only pay(amount)
function checkout(gateway, amount) {
  const res = gateway.pay(amount);
  console.log(gateway.constructor.name.padEnd(16), amount, "->", JSON.stringify(res));
}
checkout(new TakaPayAdapter(new TakaPaySdk()), 500);
checkout(new DeshCardAdapter(new DeshCardSdk()), 349.5);

TakaPayAdapter   500 -> {"ok":true,"id":"TP-1500"}
DeshCardAdapter  349.5 -> {"ok":true,"id":"DC-34950"}

নিচের ডায়াগ্রামে একটি ডাক adapter-এর ভেতর দিয়ে কীভাবে অনুবাদ হয়ে যায় আর ফিরে আসে, ধাপে ধাপে দেখুন:

const res = gateway.pay(500);
// gateway কোন SDK, checkout জানে না

amount = 500          // টাকা
paisa  = Math.round(500 * 100) = 50000
this.sdk.makePayment({ paisa: 50000, ref: "ORD" })

return { status: "OK", txn: "TP-1500" }

ok = (r.status === "OK")  // true
id = r.txn               // "TP-1500"
return { ok: true, id: "TP-1500" }

res = { ok: true, id: "TP-1500" }
// DeshCard হলে: pay(349.5) → authorize("349.50")
//   → "AUTH-34950" → capture() → { code: 0, ref: "DC-34950" }
→ { ok: true, id: "DC-34950" }

Object adapter বনাম class adapter

এই দুটিকে বলে object adapter আর class adapter. JavaScript আর Python-এ interface আলাদা ঘোষণা করা লাগে না বলে class adapter খুব কম দেখা যায়; Java, C# আর C++-এ বিশেষ ক্ষেত্রে আসে।

ফলাফল আর ফাঁদ

• লাভ: বাইরের নির্ভরতা এক জায়গায় আটকে থাকে। SDK-র নতুন version এলে, বা gateway বদলালে, বদলায় শুধু adapter. Test-এ adapter-এর বদলে একটি fake gateway বসানো যায় (test double-এর বিস্তারিত পর্ব ৪৯-এ)।
• ফাঁদ ১ — এককের ভুল: টাকা বনাম পয়সা, সেকেন্ড বনাম millisecond, UTC বনাম স্থানীয় সময়। ১৯৯৯ সালে Mars Climate Orbiter হারানোর প্রকাশিত কারণ ছিল দুই দলের সফটওয়্যারের মধ্যে unit of measure-এর অমিল (pound-force-second বনাম newton-second) — ঠিক সেই সীমানায়, যেখানে একটি adapter-এর কাজ ছিল রূপান্তর। এককের নাম variable-এ রাখুন (paisa, amountTaka) আর রূপান্তরের test লিখুন।
• ফাঁদ ২ — ফুটো adapter: target-এ SDK-র type বা error (TakaPayError) ফাঁস হলে client আবার SDK-তে বাঁধা পড়ে। Adapter-এর বাইরে শুধু আপনার নিজের type যাবে।
• ফাঁদ ৩ — adapter-এ ব্যবসার নিয়ম: “৫০০০ টাকার বেশি হলে OTP” — এটি domain-এর নিয়ম, adapter-এর নয়। Adapter শুধু অনুবাদ করবে।
• ফাঁদ ৪ — অর্থ মেলে না: দুটি API-র ধারণা পুরোপুরি না মিললে (একটি refund সমর্থন করে, আরেকটি করে না) adapter চুপচাপ “সফল” ফেরত দেবে না; স্পষ্ট error দেবে। Interface-এর contract পর্ব ৩১-এ (Interface আর contract) দেখেছেন।

বড় পরিসরে এই চিন্তাটিই architecture হয়ে ওঠে: domain-এর চারপাশে port (interface) আর বাইরের জগতের সাথে adapter — পর্ব ৪০-এ hexagonal architecture-এ আসবে। Eric Evans-এর Domain-Driven Design (২০০৩) এর একটি রূপকে বলে anti-corruption layer.

৩ · Decorator — একই interface, মোড়কের ওপর মোড়ক

উদ্দেশ্য: একটি object-এর সাথে চলার সময় বাড়তি দায়িত্ব জুড়ে দেওয়া, subclass না বানিয়ে। Decorator মূল object-এর একই interface মানে, ভেতরে মূলটিকে রাখে, আর প্রতিটি ডাকের আগে বা পরে নিজের কাজটুকু করে ডাকটি ভেতরে পাঠায়।

সমস্যা — inheritance দিয়ে করলে class-এর বিস্ফোরণ

একটি কাল্পনিক মুদ্রা-বিনিময় হারের service থেকে data আনার RateFetcher আছে। কোথাও লাগবে log, কোথাও ব্যর্থ হলে আবার চেষ্টা (retry), কোথাও ফল জমিয়ে রাখা (cache). প্রতিটি সমন্বয়ের জন্য একটি subclass বানালে: তিনটি ঐচ্ছিক বৈশিষ্ট্যে ২³ = ৮টি সমন্বয় (কিছুই না থেকে তিনটিই পর্যন্ত), চারটিতে ১৬টি — subclass explosion. তার ওপর ক্রমও আলাদা অর্থ বহন করে (নিচে দেখবেন), তাই সত্যিকারের সম্ভাবনা আরও বেশি। Decorator-এ লাগে শুধু তিনটি ছোট class, আর সমন্বয় বানানো হয় চলার সময় — মোড়ক বসিয়ে।

কাঠামো

একটি interface (DataSource, operation fetch(code)); একটি আসল বাস্তবায়ন (RateFetcher); আর decorator-গুলো, যারা নিজেরাও DataSource আর ভেতরে আরেকটি DataSource ধরে রাখে। মূল কথা: decorator ভেতরের জিনিসকে interface দিয়ে চেনে, নির্দিষ্ট class দিয়ে নয় — তাই একটি decorator আরেকটি decorator-কে মুড়তে পারে। অংশ ৮-এর ছবিতে কাঠামোটি adapter আর proxy-র পাশাপাশি দেখবেন।

ক্রম বদলালে ফল বদলায় — Python-এ চালিয়ে দেখুন

নিচের কোডে তিনটি মোড়ক — logged, retry, cached — একটি কাল্পনিক হার-সার্ভারের function-এর চারপাশে দুই রকম ক্রমে বসানো হয়েছে। সার্ভারটি প্রথম ডাকে timeout দেয়, পরে ঠিকমতো উত্তর দেয়। প্রতিটি ক্রমে একই প্রশ্ন দুবার করা হয়েছে ("USD"):

import functools
def logged(f):
    @functools.wraps(f)
    def w(code):
        print(f"  log: -> {code}"); r = f(code); print(f"  log: <- {r}"); return r
    return w
def retry(f):
    @functools.wraps(f)
    def w(code):
        for attempt in (1, 2, 3):
            try: return f(code)
            except ConnectionError as e: print(f"  retry: attempt {attempt} failed ({e})")
        raise ConnectionError("gave up")
    return w
def cached(f):
    memo = {}
    @functools.wraps(f)
    def w(code):
        if code in memo: print("  cache: hit"); return memo[code]
        memo[code] = f(code); return memo[code]
    return w
def make_fetch():                       # fictional rate server: 1st call times out
    calls = [0]
    def fetch_rate(code):
        calls[0] += 1
        if calls[0] == 1: raise ConnectionError("timeout")
        return {"USD": 122}[code]
    return fetch_rate, calls

for order in [(cached, logged, retry), (logged, retry, cached)]:
    f, calls = make_fetch()
    for deco in reversed(order): f = deco(f)   # same as @order[0] @order[1] @order[2]
    print(" > ".join(d.__name__ for d in order), "| name:", f.__name__)
    f("USD"); f("USD")
    print(f"  real calls = {calls[0]}")

cached > logged > retry | name: fetch_rate
  log: -> USD
  retry: attempt 1 failed (timeout)
  log: <- 122
  cache: hit
  real calls = 2
logged > retry > cached | name: fetch_rate
  log: -> USD
  retry: attempt 1 failed (timeout)
  log: <- 122
  log: -> USD
  cache: hit
  log: <- 122
  real calls = 2

একটি ডাক তিন স্তরের মোড়ক ভেদ করে ভেতরে যায়, আর ফল একই পথে বাইরে ফেরে। দ্বিতীয় ক্রমের (logged(retry(cached(fetch)))) প্রথম ডাকটি ধাপে ধাপে দেখুন:

1logged:  print "-> USD" … print "<- r"2  retry:  for attempt in 1..3: try3    cached: memo-তে আছে? না হলে নিচে4      fetch_rate: আসল সার্ভার

Python-এর @decorator — সম্পর্কিত, কিন্তু হুবহু এক নয়

Python-এ @cached লিখে function-এর ওপর বসালে সেটি আসলে এই লাইনের সংক্ষিপ্ত রূপ: fetch = cached(fetch). একাধিক হলে নিচ থেকে উপরে প্রয়োগ হয় — নিচের লেখাটি সবচেয়ে ভেতরের মোড়ক:

@logged          # 3rd: outermost
@retry           # 2nd
@cached          # 1st: closest to the function
def fetch_rate(code): ...
# same as: fetch_rate = logged(retry(cached(fetch_rate)))

এই Python decorator GoF Decorator-এর আত্মীয়, কিন্তু পার্থক্যগুলো জানা দরকার:

উপরের কোডে আমরা for deco in reversed(order): f = deco(f) লিখে চলার সময় মোড়ক বসিয়েছি — এটি GoF-এর চেতনার কাছাকাছি। @ syntax-এর খুঁটিনাটি (functools.wraps, argument-সহ decorator) জানতে Python কোর্সের decorator পর্বটি দেখুন। PEP 318 (Python 2.4, ২০০৪) নিজেই উল্লেখ করেছে যে “decorator” নামটি GoF-এর pattern-এর সাথে পুরো মেলে না বলে সমালোচনা হয়েছিল।

ফলাফল আর ফাঁদ

• লাভ: প্রতিটি দায়িত্ব একটি ছোট class-এ (পর্ব ২৭-এর single responsibility), নতুন দায়িত্ব যোগে পুরোনো কোড বদলায় না (open-closed), সমন্বয় চলার সময়।
• ক্রমের ভুল: উপরের log-এর উদাহরণ; বা retry-কে cache-এর ভেতরে না রেখে বাইরে রাখলে কী হয় — ভেবে দেখুন। মোড়ক কে, কোন ক্রমে বসাবে, তা এক জায়গায় রাখুন (পর্ব ৩৭-এ composition root).
• Identity হারায়: মোড়ানো object আর আসল object আলাদা; === বা is দিয়ে তুলনা, বা instanceof RateFetcher যাচাই ভেঙে যায়।
• অনেক ছোট object আর লম্বা stack trace: debug করার সময় পাঁচ স্তরের মোড়ক পেরিয়ে আসল কোডে পৌঁছাতে হয়।
• Interface মোটা হলে কষ্ট: interface-এ ২০টি method থাকলে প্রতিটি decorator-কে ২০টিই ভেতরে পাঠাতে হয় — পর্ব ২৮-এর interface segregation এখানে সরাসরি সাহায্য করে।
• Strategy-র সাথে গুলিয়ে ফেলা: GoF-এর ভাষায় decorator object-এর “চামড়া” বদলায় (বাইরে থেকে মোড়ে), আর strategy বদলায় “ভেতরের অঙ্গ” (ভেতরের algorithm). Strategy পর্ব ৩৫-এ (Behavioral pattern ১)।

৪ · Facade — জটিল subsystem-এর একটি সহজ দরজা

উদ্দেশ্য: একটি subsystem-এর অনেকগুলো interface-এর সামনে একটি একক, উঁচু স্তরের interface দেওয়া, যাতে subsystem ব্যবহার সহজ হয়। Facade (ফরাসি শব্দ, বাড়ির সামনের দিক) নতুন কোনো ক্ষমতা যোগ করে না; শুধু সাধারণ কাজগুলোকে একটি পরিষ্কার পথে সাজায়।

সমস্যা: কাল্পনিক অনলাইন বাজার অ্যাপে একটি অর্ডার নিতে stock সংরক্ষণ, payment, ডেলিভারির ঠিকানা যাচাই, ডেলিভারি বুকিং আর SMS — পাঁচটি subsystem পরপর ডাকতে হয়, নির্দিষ্ট ক্রমে, আর মাঝপথে ব্যর্থ হলে আগের কাজ ফিরিয়ে নিতে হয়। এই ক্রম যদি mobile app-এর controller, web-এর controller আর admin panel-এ তিন জায়গায় লেখা থাকে, তিনটি আলাদা হয়ে যাবেই। Facade এই ক্রমকে এক জায়গায় তোলে:

class OrderFacade {
  constructor(stock, payments, delivery, sms) { Object.assign(this, { stock, payments, delivery, sms }); }
  placeOrder(cart, customer) {                 // the one simple entry point
    const hold = this.stock.reserve(cart.items);
    const paid = this.payments.pay(cart.total);   // e.g. an adapter from section 2
    if (!paid.ok) { this.stock.release(hold); return { ok: false, reason: "payment" }; }
    const slot = this.delivery.book(customer.address, hold);
    this.sms.send(customer.phone, "Order confirmed: " + paid.id);
    return { ok: true, paymentId: paid.id, slot };
  }
}

এটি একটি নকশার খসড়া (চালানোর জন্য নয়)। খেয়াল করুন, payments এখানে আগের অংশের adapter-ই হতে পারে — pattern-গুলো একসাথে কাজ করে।

ফলাফল আর ফাঁদ

• লাভ: client-এর coupling কমে — পাঁচটির বদলে একটি জিনিস চেনে (পর্ব ২৫-এর coupling, পর্ব ২৬-এর Law of Demeter). ক্রম আর ভুল সামলানোর নিয়ম এক জায়গায়।
• সব লুকানো নয়: GoF স্পষ্টই বলে, facade থাকলেও যাঁদের দরকার, তাঁরা subsystem-এর class সরাসরি ব্যবহার করতে পারেন। Facade মানে “একমাত্র পথ” নয়, “সহজ পথ”।
• ফাঁদ — god class: সব নতুন কাজ facade-এ গুঁজে দিলে সেটি শত শত method-এর একটি দানব হয়। সমাধান: কাজের ধরন অনুযায়ী একাধিক ছোট facade (অর্ডার, রিপোর্ট, প্রশাসন)।
• ফাঁদ — ব্যবসার যুক্তি জমা হওয়া: facade সমন্বয় করে; ছাড়ের হিসাব বা stock-এর নিয়মের মতো domain-এর সিদ্ধান্ত subsystem-এ থাকবে।

Network-এর স্তরে একই চিন্তার রূপ হলো API gateway — অনেক service-এর সামনে একটি দরজা; এর বিস্তারিত System Design কোর্সের reverse proxy, API gateway আর BFF পর্বে।

৫ · Proxy — একই interface-এর পেছনে প্রবেশ নিয়ন্ত্রণ

উদ্দেশ্য: আরেকটি object-এর কাছে যাওয়া নিয়ন্ত্রণ করতে তার একটি প্রতিনিধি (surrogate) রাখা। Proxy আসল object-এর হুবহু একই interface মানে, তাই client টেরই পায় না যে সে প্রতিনিধির সাথে কথা বলছে।

চার রকম প্রচলিত proxy

এগুলোকে বলে virtual proxy, protection proxy, remote proxy আর caching proxy.

JavaScript-এর Proxy — pattern যখন ভাষার অংশ

ES2015 থেকে JavaScript-এ Proxy নামে একটি ভাষাগত সুবিধা আছে: new Proxy(target, handler). Handler-এর get, set, has, apply ইত্যাদি method — যাদের বলে trap — target-এর ওপর প্রতিটি মৌলিক কাজ (property পড়া, লেখা, function ডাকা) মাঝপথে ধরে ফেলে। প্রতিটি trap-এর সমনামী একটি default আচরণ Reflect-এ পাওয়া যায়। এর ফলে proxy-র জন্য প্রতিটি method হাতে হাতে লিখতে হয় না। নিচে একটি caching proxy, যা আসল ডাক গুনে দেখায়:

// A fictional slow rate service (pretend each call goes over the network)
let realCalls = 0;
const rateService = {
  getRate(code) { realCalls++; return { USD: 122, EUR: 131, INR: 1.45 }[code]; },
  name: "demo-rates",
};

// Caching proxy built with the language's Proxy object
function withCache(target) {
  const memo = new Map();
  return new Proxy(target, {
    get(obj, prop, receiver) {
      const value = Reflect.get(obj, prop, receiver);
      if (typeof value !== "function") return value;      // plain fields pass through
      return (...args) => {
        const key = prop + ":" + JSON.stringify(args);
        if (!memo.has(key)) memo.set(key, value.apply(obj, args));
        return memo.get(key);
      };
    },
  });
}

const rates = withCache(rateService);       // same interface as rateService
const asked = ["USD", "EUR", "USD", "USD", "INR", "EUR"];
for (const c of asked) console.log(c, rates.getRate(c));
console.log("asked:", asked.length, "| real calls:", realCalls, "| name:", rates.name);
console.log("is rates === rateService?", rates === rateService);

USD 122
EUR 131
USD 122
USD 122
INR 1.45
EUR 131
asked: 6 | real calls: 3 | name: demo-rates
is rates === rateService? false

বাস্তবে Vue 3-এর reactivity-ব্যবস্থা এই ভাষাগত Proxy-র ওপর দাঁড়িয়ে (property পড়া আর লেখা ধরে UI হালনাগাদ করে)। Java-তে একই ধারণা java.lang.reflect.Proxy (JDK 1.3) — Spring-এর মতো framework লেনদেন বা নিরাপত্তার নিয়ম proxy দিয়েই জোড়ে। ভাষাগত Proxy-র আরও trap আর Reflect-এর বিস্তারিত JavaScript কোর্সের Symbol, Proxy আর Reflect পর্বে।

ফলাফল আর ফাঁদ

• লাভ: প্রবেশ-নিয়ন্ত্রণের কাজ (অনুমতি, lazy load, cache) আসল class থেকে আলাদা থাকে; আসল class নিজের কাজেই মন দেয়।
• লুকানো latency: remote proxy একটি network ডাককে স্থানীয় method-এর মতো দেখায়। লুপের ভেতরে order.customer.name লিখলে প্রতিবার একটি database query বা network ডাক যেতে পারে (ORM-এর কুখ্যাত “N+1 query” সমস্যা)। Network ব্যর্থ হতে পারে, ধীর হতে পারে — স্থানীয় ডাক তা হয় না।
• বাসি cache: caching proxy-র ফল কতক্ষণ বৈধ? আসল হার বদলালে memo পুরোনো হয়ে যায়। মেয়াদ (TTL) আর বাতিল করার নিয়ম ছাড়া cache একটি bug-কারখানা।
• Decorator-এর সাথে পার্থক্য: কাঠামো প্রায় এক। পার্থক্য উদ্দেশ্যে আর সম্পর্কের মালিকানায়: proxy সাধারণত নিজেই ঠিক করে আসল object কখন তৈরি হবে আর কাকে ঢুকতে দেবে; decorator বাইরে থেকে দেওয়া object-কে মুড়ে নতুন আচরণ যোগ করে আর মোড়ক জমানো যায়। উপরের caching proxy-কে decorator বললেও খুব ভুল হবে না — নাম বেছে নিন পাঠককে কী জানাতে চান, সেই অনুযায়ী।

৬ · Composite — অংশ আর পুরোকে একই চোখে দেখা

উদ্দেশ্য: object-গুলোকে গাছের কাঠামোয় সাজিয়ে part-whole hierarchy বোঝানো, যাতে client একটি একক জিনিস আর জিনিসের দলকে একইভাবে ব্যবহার করতে পারে। Composite-এ দুই রকম অংশ: leaf (নিচে আর কিছু নেই, যেমন একটি পণ্য) আর composite (ভেতরে আরও অংশ, যেমন একটি বান্ডিল) — দুটিরই একই interface.

// Composite: a fictional shop's order — items and bundles share one interface
class Item {                               // leaf
  constructor(name, price) { this.name = name; this.price = price; }
  total() { return this.price; }
  print(indent = "") { console.log(`${indent}- ${this.name}: ${this.total()}`); }
}
class Bundle {                             // composite: holds children
  constructor(name, discountPct = 0) { this.name = name; this.discountPct = discountPct; this.children = []; }
  add(...parts) { this.children.push(...parts); return this; }
  total() {
    const sum = this.children.reduce((s, c) => s + c.total(), 0);  // recursion
    return Math.round(sum * (100 - this.discountPct) / 100);
  }
  print(indent = "") {
    const off = this.discountPct ? ` (-${this.discountPct}%)` : "";
    console.log(`${indent}+ ${this.name}${off}: ${this.total()}`);
    this.children.forEach(c => c.print(indent + "    "));
  }
}

const sweets = new Bundle("Sweets box", 10).add(new Item("Roshogolla 1kg", 400), new Item("Sondesh 500g", 300));
const gift = new Bundle("Eid gift box").add(new Item("Panjabi", 1500), sweets, new Item("Attar", 250));
const order = new Bundle("Order #42").add(gift, new Item("Delivery", 60));

order.print();
// The client treats a leaf and a whole tree the same way:
for (const part of [new Item("Pen", 20), order]) console.log(part.constructor.name, "total =", part.total());

+ Order #42: 2440
    + Eid gift box: 2380
        - Panjabi: 1500
        + Sweets box (-10%): 630
            - Roshogolla 1kg: 400
            - Sondesh 500g: 300
        - Attar: 250
    - Delivery: 60
Item total = 20
Bundle total = 2440

1+ Order #422    + Eid gift box3        - Panjabi 15004        + Sweets box (-10%)5            - Roshogolla 4006            - Sondesh 3007        - Attar 2508    - Delivery 60

নকশার একটি বাছাই — স্বচ্ছতা বনাম নিরাপত্তা

add() method কোথায় থাকবে? GoF দুটি পথ আলোচনা করে। স্বচ্ছতা (transparency): সাধারণ interface-এ add() রাখুন, যাতে client কখনো leaf আর composite আলাদা করতে না হয় — কিন্তু তখন leaf-এ add() ডাকা যায়, যা অর্থহীন, তাই সেখানে error দিতে হয় (পর্ব ২৮-এর Liskov substitution-এর সাথে টানাপোড়েন)। নিরাপত্তা (safety): add() শুধু composite-এ, যেমন উপরের কোডে — ভুল ডাক compile-এর সময় বা পড়ার সময়ই ধরা পড়ে, কিন্তু গাছ বানানোর সময় client-কে জানতে হয় কোনটি composite. আধুনিক কোডে সাধারণত দ্বিতীয় পথই বেশি দেখা যায়।

• ফাঁদ — চক্র: একটি bundle-কে ভুল করে নিজের ভেতরেই যোগ করলে total() অসীম recursion-এ পড়ে। add()-এ চক্র যাচাই রাখুন।
• ফাঁদ — খুব গভীর গাছ: হাজার স্তরের গাছে recursion stack-এর সীমা ছুঁতে পারে; তখন নিজের stack দিয়ে লুপ।
• ফাঁদ — instanceof দিয়ে শাখা: client যদি “leaf হলে এটা, bundle হলে ওটা” লেখে, pattern-এর মূল লাভটাই হারায়। গাছের ওপর নতুন নতুন কাজ (দাম, ওজন, কর) লাগলে visitor pattern (পর্ব ৩৬, Behavioral pattern ২) সাহায্য করে; গাছ ঘুরে দেখার জন্য iterator-ও সেখানে।

৭ · Bridge আর Flyweight — সংক্ষেপে

Bridge — দুই দিকের বৈচিত্র্য আলাদা রাখা

Bridge-এর উদ্দেশ্য: abstraction আর তার implementation-কে আলাদা করা, যাতে দুটি স্বাধীনভাবে বদলাতে পারে। একটি কাল্পনিক অঙ্কন-অ্যাপে আকৃতি তিনটি (বৃত্ত, বর্গ, ত্রিভুজ), আর আঁকার পদ্ধতি দুটি (পর্দায় SVG, ছাপার জন্য PDF). Inheritance দিয়ে করলে SvgCircle, PdfCircle, SvgSquare… — ৩ × ২ = ৬টি class. নতুন একটি আকৃতি মানে আরও ২টি, নতুন একটি renderer মানে আরও ৩টি। Bridge-এ Shape-এর ভেতরে একটি Renderer-এর reference থাকে: new Circle(new SvgRenderer()). Class লাগে ৩ + ২ = ৫টি, আর ৫টি আকৃতি × ৩টি renderer হলে ১৫-এর বদলে ৮টি।

Adapter-এর সাথে পার্থক্য: adapter বানানো হয় পরে, দুটি আগে থেকে থাকা অমিল জিনিস জুড়তে; bridge পরিকল্পনা করা হয় আগে, যাতে দুই দিক আলাদাভাবে বাড়তে পারে। Database driver-এর নকশা (JDBC-র মতো) — application-এর API একদিকে, প্রতিটি database-এর driver আরেক দিকে — bridge-এর চিন্তার কাছাকাছি।

Flyweight — অভিন্ন অংশ ভাগাভাগি

Flyweight-এর উদ্দেশ্য: ভাগাভাগি করে বিপুলসংখ্যক ছোট object দক্ষতার সাথে রাখা। কৌশলটি হলো object-এর অবস্থাকে দুই ভাগ করা: intrinsic state — যা সব জায়গায় একই (একটি অক্ষরের আকৃতি, একটি map tile-এর ছবি), একবার রেখে ভাগ করা হয়; আর extrinsic state — যা প্রতিটি ব্যবহারে আলাদা (পাতায় অক্ষরের অবস্থান, map-এ tile-এর স্থানাঙ্ক), ডাকের সময় বাইরে থেকে দেওয়া হয়। GoF-এর নিজের উদাহরণ ছিল একটি document editor-এর অক্ষর (glyph).

Flyweight-এর শর্ত: ভাগ করা অংশ অবশ্যই immutable হতে হবে — একজন বদলালে সবার বদলে যাবে। বাস্তবে Java-র Integer.valueOf −১২৮ থেকে ১২৭-এর মান cache করে, আর অনেক ভাষা একই string literal ভাগ করে (string interning) — দুটিই flyweight-এর রূপ। ভাবনার প্রশ্ন ৫-এ এর একটি বিখ্যাত ফাঁদ দেখবেন।

৮ · পাশাপাশি তুলনা — Adapter, Facade, Proxy আর Decorator

চারটি pattern-ই “একটি জিনিস আরেকটিকে মুড়ে রাখে”, তাই কোড দেখে প্রায়ই একই রকম লাগে। আলাদা করার দুটি প্রশ্ন: (১) বাইরের interface কি ভেতরেরটির মতোই? (২) মোড়কটি কেন আছে? নিচের ছবিতে তিনটির UML কাঠামো পাশাপাশি:

একটি মনে রাখার কৌশল: Adapter — কথা অনুবাদ করে; Facade — কথা সংক্ষেপ করে; Proxy — কথা পাহারা দেয়; Decorator — কথার সাথে কিছু যোগ করে। কাঠামো এক হলেও নাম আলাদা রাখার কারণ এটাই: নামটি পরের পাঠককে বলে দেয় মোড়কটি কেন আছে। Composite আলাদা জাতের — সে একটির বদলে অনেকটিকে মুড়ে একটির মতো দেখায়; আর chain of responsibility-ও (পর্ব ৩৬) decorator-এর মতো শিকল, তবে সেখানে যে-কোনো স্তর ডাকটি থামিয়ে দিতে পারে।

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

AI কোড-সহকারী pattern-এর নাম খুব ভালোবাসে। “একটি adapter বানাও” বললে সে প্রায় নিখুঁত দেখতে কোড দেয়। সমস্যা হয় সূক্ষ্ম জায়গায় — এককের রূপান্তর, error-এর অনুবাদ, মোড়কের ক্রম আর UML-এর তীর।

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

• প্রতিটি pattern-এর পেছনে আজকের একটি বাস্তব কারণ আছে — “ভবিষ্যতে লাগতে পারে” নয়
• Adapter-এর একক-রূপান্তর আর error-অনুবাদের জন্য আলাদা test আছে, আর সেগুলো ভুল বাস্তবায়নে ব্যর্থ হয় (mutation test-এর ধারণা, পর্ব ৫০)
• Decorator-এর ক্রম এক জায়গায় লেখা, আর প্রতিটি ক্রমের অর্থ মন্তব্যে বলা
• Cache-এর মেয়াদ আর বাতিলের নিয়ম আছে; ব্যর্থতা cache হয় না
• UML ছবির প্রতিটি তীর আর হীরা পর্ব ২৯-এর নিয়মে মিলিয়েছি
• AI যে library বা SDK method-এর নাম দিয়েছে, official documentation-এ আছে কি না দেখেছি; বাইরে থেকে কপি করা কোডের license দেখেছি
• Prompt-এ কোনো আসল key, password বা গ্রাহকের তথ্য দিইনি