Dependency injection আর composition — inversion of control আর inheritance-এর বদলে composition

১ · সমস্যা — class-এর ভেতরে লুকানো new

পর্ব ২৮-এ তিনটি নাম আলাদা করেছিলেন: dependency inversion একটি নীতি (নির্ভরতার তীর কোন দিকে, abstraction-এর মালিক কে), dependency injection একটি কৌশল (object তার dependency কোথা থেকে পায়), আর inversion of control একটি বড় ধারণা (প্রবাহ কে চালায়)। সেখানে কথা দেওয়া ছিল, injection-এর কৌশলগুলো আর DI container-এর ভেতরের কাজ এই পর্বে আসবে। মডিউল ৬-এর pattern-গুলো (পর্ব ৩২ থেকে পর্ব ৩৬) দেখলে লক্ষ করবেন, প্রায় প্রতিটির ভেতরে একটি object আরেকটি object-কে “হাতে পায়” — strategy পায় তার algorithm, decorator পায় যাকে সে মোড়ায়, observer-এর subject পায় তার শ্রোতাদের। হাতে পাওয়াটা কে, কোথায়, কীভাবে করে — এই পর্বের বিষয় সেটিই।

কোডে প্রথম দোকানদারকে চেনা যায় class-এর ভেতরের new (Python-এ সরাসরি class ডেকে object বানানো) দেখে। একটি কাল্পনিক মুদি-দোকানের হিসাব app-এর ReportService প্রতি মাসে দোকান-মালিককে বিক্রির রিপোর্ট email করে। প্রথম সংস্করণে সে নিজের constructor-এ SmtpMailer() বানায়। এতে তিনটি সমস্যা:

1. লুকানো নির্ভরতা (hidden dependency): ReportService()-এর signature দেখে বোঝার উপায় নেই যে এটি চালাতে mail server লাগবে। Caller জানতে পারেন কেবল চালানোর পর, error পেয়ে।
2. Test করা যায় না: “ঋণাত্মক মোট হলে mail যাবে না” — এই নিয়ম যাচাই করতে গেলেও আসল SMTP server-এ সংযোগের চেষ্টা হয়। Test ধীর, পরিবেশ-নির্ভর, আর কখনো কখনো অকারণে ব্যর্থ।
3. অনমনীয়: SMS বা অন্য কোনো email সেবায় যেতে হলে ReportService-এর কোড খুলতে হবে, যদিও রিপোর্টের নিয়মে কোনো বদল নেই — পর্ব ২৭-এর open-closed-এর উল্টো।

নিচের কোডে আগে আর পরে পাশাপাশি। SmtpMailer এখানে ইচ্ছা করে ConnectionError ছোড়ে, যেন test চালানোর যন্ত্রে mail server নেই। দ্বিতীয় সংস্করণে mailer আসে constructor-এর parameter হয়ে; test-এ বসে FakeMailer, যা mail পাঠায় না, শুধু কে কী পাঠাতে চাইল তা লিখে রাখে।

class SmtpMailer:                          # the real detail
    def send(self, to, subject, body):
        raise ConnectionError("cannot reach smtp.example.com:587")

class ReportServiceV1:                     # BEFORE: hard-wired new
    def __init__(self):
        self.mailer = SmtpMailer()         # hidden dependency
    def send_monthly(self, shop, total):
        self.mailer.send(f"{shop}@example.com", "Monthly report", f"total={total}")

class ReportService:                       # AFTER: constructor injection
    def __init__(self, mailer):
        self.mailer = mailer               # any object with send(to, subject, body)
    def send_monthly(self, shop, total):
        if total < 0: raise ValueError("total cannot be negative")
        self.mailer.send(f"{shop}@example.com", "Monthly report", f"total={total}")

class FakeMailer:                          # records calls instead of sending
    def __init__(self): self.sent = []
    def send(self, to, subject, body): self.sent.append((to, subject, body))

def check(name, fn):
    try: fn(); print("PASS", name)
    except Exception as e: print("FAIL", name, "->", type(e).__name__, e)

def test_v1(): ReportServiceV1().send_monthly("rahim-store", 5200)
def test_sends_one_mail():
    fake = FakeMailer()
    ReportService(fake).send_monthly("rahim-store", 5200)
    assert fake.sent == [("rahim-store@example.com", "Monthly report", "total=5200")]
def test_negative_sends_nothing():
    fake = FakeMailer()
    try: ReportService(fake).send_monthly("rahim-store", -1); assert False
    except ValueError: assert fake.sent == []
for t in (test_v1, test_sends_one_mail, test_negative_sends_nothing): check(t.__name__, t)

FAIL test_v1 -> ConnectionError cannot reach smtp.example.com:587
PASS test_sends_one_mail
PASS test_negative_sends_nothing

২ · Injection-এর চার রূপ

Martin Fowler-এর ২০০৪ সালের প্রবন্ধে (বিস্তারিত অংশ ৫-এ) তিনটি রূপের নাম আসে — constructor, setter আর interface injection; চতুর্থটি, method বা parameter injection, পরে অনেক লেখক আলাদা করে দেখান। চারটির একটিই প্রশ্ন: dependency কোন দরজা দিয়ে ঢোকে?

class ReportService:
    def __init__(self, mailer, repo):         # constructor: required
        self.mailer, self.repo = mailer, repo
        self.logger = NullLogger()            # setter target: optional, safe default

    def render(self, month, formatter):       # method: varies per call
        return formatter.format(self.repo.sales(month))

svc = ReportService(SmtpMailer(cfg), SqlSalesRepo(cfg))
svc.logger = FileLogger("report.log")         # setter / property injection
print(svc.render("2026-03", BanglaFormatter()))

এই উদাহরণ (চালানোর জন্য নয়, শুধু আকার দেখানোর জন্য) একটি প্রচলিত সুপারিশ মানে: যা বাধ্যতামূলক, তা constructor-এ; যা ঐচ্ছিক, তার জন্য নিরাপদ default আর setter; যা প্রতিবার বদলায়, তা method-এর parameter-এ। Constructor injection-এর প্রধান সুবিধা হলো, object তৈরি হওয়ার মুহূর্তেই সম্পূর্ণ — কোনো “আধা-তৈরি” অবস্থা নেই, আর field-গুলো চাইলে অপরিবর্তনীয় রাখা যায় (পর্ব ৩১-এর immutability). NullLogger হলো এমন একটি object যা কিছুই করে না — “logger নেই” বোঝাতে None পরীক্ষার বদলে এটি বসালে কোডে if self.logger: ছড়াতে হয় না।

৩ · Composition root — সব জোড়া এক জায়গায়

প্রতিটি class যদি বলে “আমাকে দিন, আমি বানাব না”, তাহলে প্রশ্ন জাগে: শেষ পর্যন্ত বানাবে কে? উত্তর: একটি জায়গা, program-এর একেবারে শুরুর কাছে। Mark Seemann এই জায়গার নাম দেন composition root — তাঁর Dependency Injection in .NET (২০১১) বইয়ে এই ধারণাটি কেন্দ্রীয়, বলে সাধারণত উল্লেখ করা হয়। Console app-এ এটি main(), web app-এ server চালু হওয়ার কোড, test-এ প্রতিটি test-এর শুরুর অংশ। নিয়মটি সরল: object বানানো আর জোড়া হবে composition root-এ; বাকি সব কোড কেবল যা পেয়েছে তা ব্যবহার করবে।

নিচের stepper-এ composition root লাইন ধরে চলছে। খেয়াল করুন, ক্রমটি dependency graph-এর নিচ থেকে ওপরে: যার কোনো নির্ভরতা নেই (Config) সে আগে, যে সবার ওপর নির্ভর করে (Scheduler) সে শেষে।

এই জোড়া হাতে লেখা — কোনো library ছাড়া, সাধারণ constructor ডেকে। Seemann একে প্রথমে “Poor Man's DI” বলতেন, পরে নাম বদলে pure DI রাখেন, কারণ এটি দুর্বল বিকল্প নয় — অনেক সময় সবচেয়ে ভালো বিকল্প। Python-এ এর আকার:

def main():                                   # the composition root
    config = Config.load("shop.toml")
    mailer = SmtpMailer(config)
    repo = SqlSalesRepo(config)
    report = ReportService(repo, mailer)
    Scheduler(report).start()

if __name__ == "__main__":
    main()

৪ · Pure DI বনাম DI container

পাঁচটি object হাতে জোড়া সহজ। কিন্তু একটি বড় web app-এ দুই-তিনশো class থাকতে পারে, আর প্রতিটি web request-এর জন্য কিছু object নতুন করে বানাতে হয়। তখন অনেক দল একটি DI container ব্যবহার করে — একটি library, যা “কোন নামের জিনিস কীভাবে বানাতে হয়” তার তালিকা রাখে আর চাইলে পুরো graph নিজেই বানিয়ে দেয়। Container তিনটি কাজ করে:

• Registration (নিবন্ধন): composition root-এ বলে দেওয়া — “mailer চাইলে SmtpMailer দেবে, তার লাগবে config.”
• Resolution (সমাধান): কেউ orders চাইলে container তার dependency-গুলো খোঁজে, সেগুলোর dependency খোঁজে — graph-এর নিচ পর্যন্ত — তারপর নিচ থেকে ওপরে বানায়, ঠিক stepper ১-এর ক্রমে।
• Lifetime (আয়ুষ্কাল) ব্যবস্থাপনা: প্রতিবার নতুন object, না একটিই সবার জন্য? এর উত্তর service lifetime.

Container-এর “singleton lifetime” আর পর্ব ৩৩-এর Singleton pattern এক জিনিস নয়। Pattern-এ class নিজেই নিশ্চিত করে যে তার একটিই object হবে, আর সেটি global ভাবে যে কেউ নিতে পারে — ফলে লুকানো নির্ভরতা আর test-এ বদলানোর কষ্ট। Container-এর singleton-এ class একেবারে সাধারণ; “একটিই হবে” সিদ্ধান্তটি composition root-এর, আর object পৌঁছায় constructor দিয়ে, global দিয়ে নয়। Test-এ আপনি নির্দ্বিধায় নতুন একটি বানাতে পারেন।

অনেক container আরও একটি সুবিধা দেয় — auto-wiring: constructor-এর parameter-এর type বা নাম দেখে container নিজেই বোঝে কী দিতে হবে, প্রতিটি জোড়া হাতে লিখতে হয় না। সুবিধা হলো কম কোড; মূল্য হলো জোড়া চোখে দেখা যায় না, আর ভুল অনেক সময় ধরা পড়ে compile-এর সময় নয়, app চালু হওয়ার বা প্রথম ব্যবহারের সময়।

নিচের stepper আর তারপরের কোডে ৩০ লাইনের একটি খেলনা container — বাস্তব container-এর মূল কৌশল দেখানোর জন্য, ব্যবহারের জন্য নয়। এতে আছে registration, recursion দিয়ে resolution, transient আর singleton lifetime, আর একটি dependency cycle ধরার উপায়: resolve করার সময় “এখন কোন পথে আছি” তার একটি তালিকা (path) রাখা; একই নাম পথে দ্বিতীয়বার এলেই বৃত্ত।

// A tiny DI container: register, resolve, lifetimes, cycle detection.
class Container {
  constructor() { this.regs = new Map(); this.single = new Map(); this.made = 0; }
  register(name, deps, factory, life = "transient") {
    this.regs.set(name, { deps, factory, life });
  }
  resolve(name, path = []) {
    if (path.includes(name)) throw new Error("cycle: " + [...path, name].join(" -> "));
    const r = this.regs.get(name);
    if (!r) throw new Error("not registered: " + name);
    if (r.life === "singleton" && this.single.has(name)) return this.single.get(name);
    const args = r.deps.map(d => this.resolve(d, [...path, name]));
    const obj = r.factory(...args); obj.id = name + "#" + (++this.made);
    if (r.life === "singleton") this.single.set(name, obj);
    return obj;
  }
}
const c = new Container();
c.register("config", [], () => ({ smsSender: "SHOP" }), "singleton");
c.register("sms", ["config"], cfg => ({ cfg }), "singleton");
c.register("repo", [], () => ({ rows: [] }));            // transient
c.register("orders", ["repo", "sms"], (repo, sms) => ({ repo, sms }));
const a = c.resolve("orders"), b = c.resolve("orders");
console.log("a:", a.id, "repo", a.repo.id, "sms", a.sms.id, "cfg", a.sms.cfg.id);
console.log("b:", b.id, "repo", b.repo.id, "sms", b.sms.id);
console.log("same sms?", a.sms === b.sms, "| same repo?", a.repo === b.repo);
console.log("objects made:", c.made);
c.register("billing", ["invoice"], inv => ({ inv }));
c.register("invoice", ["tax"], tax => ({ tax }));
c.register("tax", ["billing"], bill => ({ bill }));
try { c.resolve("billing"); } catch (e) { console.log("error ->", e.message); }

a: orders#4 repo repo#1 sms sms#3 cfg config#2
b: orders#6 repo repo#5 sms sms#3
same sms? true | same repo? false
objects made: 6
error -> cycle: billing -> invoice -> tax -> billing

বিভিন্ন ecosystem-এ container — সাধারণ পরিচয়

লেখার সময়ে প্রায় প্রতিটি বড় ecosystem-এ DI container বা DI-সমর্থিত framework আছে। নিচের বর্ণনা সাধারণ; খুঁটিনাটি version-ভেদে বদলায়, তাই ব্যবহারের আগে সংশ্লিষ্ট documentation দেখুন। এখানে কোনোটিকে সুপারিশ করা হচ্ছে না।

কোনটি বেছে নেবেন — pure DI না container? Pure DI-তে জোড়া সাধারণ কোড: IDE-তে “definition-এ যান” চাপলেই দেখা যায় কী কোথায় গেল, ভুল type দিলে type checker বা compiler ধরে, শেখার কিছু নেই। Container-এ লাভ আসে বড় graph-এ, অনেক scoped object-এ, আর framework যখন নিজেই container দেয় (তখন তার বিপরীতে যাওয়া অর্থহীন)। পর্ব ২৬-এর YAGNI এখানে প্রযোজ্য: ছোট বা মাঝারি app-এ pure DI দিয়ে শুরু করুন; জোড়ার কোড সত্যিই অসহনীয় হলে container আনুন — তখন composition root আগে থেকেই এক জায়গায় থাকায় বদলটিও এক জায়গায় হবে।

৫ · Inversion of control, service locator আর over-injection

Service locator — নির্ভরতা আবার লুকানো

Service locator হলো একটি global রেজিস্টার, যার কাছে class নিজেই চেয়ে নেয়: Locator.get("mailer"). দেখতে DI-এর মতো — class তো SmtpMailer() বানাচ্ছে না! কিন্তু dependency-র দিক আবার উল্টে গেছে: class নিজে টেনে আনছে (pull), বাইরে থেকে ঠেলে দেওয়া হচ্ছে না (push).

class ReportService:                     # service locator: dependencies hidden
    def __init__(self):
        pass                             # signature says: "I need nothing"
    def send_monthly(self, shop, total):
        mailer = Locator.get("mailer")   # discovered only when this line runs
        repo = Locator.get("repo")
        ...

class ReportService:                     # DI: dependencies in the signature
    def __init__(self, repo, mailer):
        self.repo, self.mailer = repo, mailer

Seemann-এর যুক্তির সারকথা: (১) signature মিথ্যা বলে — ReportService() খালি constructor দেখায়, অথচ ভেতরে দুটি জিনিস লাগে; (২) ভুল ধরা পড়ে দেরিতে — কেউ “repo” নিবন্ধন করতে ভুললে error আসে মাসের শেষে, যেদিন send_monthly প্রথম চলে; (৩) test-এ অনুমান — কোন কোন নাম locator-এ বসাতে হবে, তা জানতে class-এর ভেতরের কোড পড়তে হয়, আর এক test-এর বসানো জিনিস global বলে আরেক test-এ চুইয়ে পড়তে পারে; (৪) সবাই locator-এর ওপর নির্ভরশীল — প্রতিটি class একটি নির্দিষ্ট infrastructure-কে চেনে। ন্যায্যতার খাতিরে: Fowler নিজে service locator-কে গ্রহণযোগ্য বিকল্প বলেছিলেন, আর কিছু জায়গায় এটি প্রায় অনিবার্য — যেমন framework যখন আপনার class নিজে বানায় আর constructor-এ কিছু দিতে দেয় না, বা পুরোনো কোডে ধাপে ধাপে DI আনার মাঝপথে। তখনও নিয়ম হলো: locator ডাকার কাজটি composition root-এর কাছে, সীমানায় সীমিত রাখুন, business কোডের ভেতরে ছড়িয়ে নয়।

Constructor over-injection — parameter গুনেই সন্দেহ

Constructor injection-এর একটি “অসুবিধা” প্রায়ই বলা হয়: কিছু class-এর constructor-এ আট-দশটি parameter হয়ে যায়। কিন্তু এটি injection-এর দোষ নয়, বরং তার উপহার — দোষটি আগেও ছিল, শুধু লুকানো ছিল। Seemann এই লক্ষণকে constructor over-injection নামে একটি code smell বলেন: এতগুলো সহযোগী লাগছে মানে class-টি সম্ভবত অনেক দায়িত্ব নিয়েছে — পর্ব ২৭-এর single responsibility principle-এর লঙ্ঘন, হয়তো একটি উঠতি god class. কোনো সংখ্যার নিয়ম নেই; অনেকে চার-পাঁচটির বেশি হলে থেমে ভাবেন।

যা করবেন না: setter injection-এ সরিয়ে parameter লুকানো, বা সব dependency একটি “context” বস্তায় ভরে একটি parameter বানানো — এতে সংখ্যা কমে, সমস্যা কমে না। যা করতে পারেন: দেখুন কোন dependency-গুলো সবসময় একসাথে ব্যবহার হয়। ধরুন একটি কাল্পনিক অনলাইন বাজারের CheckoutService নেয় cart_repo, price_rules, coupon_repo, tax_table, payment_gateway, fraud_check, sms, email, audit_log — নয়টি। প্রথম চারটি মিলে আসলে একটি কাজ: “এই cart-এর চূড়ান্ত দাম বের করা।” সেগুলো একটি নতুন PricingService-এ যায়; sms আর email একটি Notifier-এ। এখন CheckoutService(pricing, payment_gateway, fraud_check, notifier, audit_log) — পাঁচটি, আর প্রতিটি একটি স্পষ্ট ভূমিকা। Seemann এই কৌশলকে facade service-এ refactor করা বলেন; এটি পর্ব ৩৪-এর facade-এর আত্মীয়, তবে লক্ষ্য এখানে দায়িত্ব ভাগ।

৬ · Functional ধাঁচে DI — function, closure আর partial application

Class না থাকলেও dependency থাকে। Functional ধাঁচের কোডে DI-এর সবচেয়ে সরল রূপ: dependency হলো function-এর argument. বারবার একই জিনিস দিতে না চাইলে দুটি কৌশল আছে। একটি closure: একটি function অন্য একটি function ফেরত দেয়, আর ভেতরের function বাইরের function-এর variable মনে রাখে — dependency একবার দেওয়া হয়, ভেতরের function যতবার ডাকা হোক, সেগুলো হাতের কাছে থাকে। অন্যটি partial application: অনেক argument-এর একটি function-এর প্রথম কয়েকটি argument আগেই বসিয়ে দিয়ে ছোট একটি function বানানো। JavaScript-এর closure নতুন মনে হলে JavaScript কোর্সের closure-এর পর্বটি পাশে রাখতে পারেন; এগুলো higher-order function-এর ব্যবহার।

// Functional DI: dependencies are just function arguments, fixed by closures.
const makePlaceOrder = ({ save, notify, now }) =>      // inject once...
  (item, qty) => {                                     // ...use many times
    if (qty <= 0) return "rejected";
    const order = { item, qty, at: now() };
    save(order);
    notify(`order ${item} x${qty} at ${order.at}`);
    return "placed";
  };

// Partial application: fix the first argument, get a smaller function.
const partial = (fn, ...first) => (...rest) => fn(...first, ...rest);
const discount = (percent, price) => price - (price * percent) / 100;
const eidDiscount = partial(discount, 10);

// Production-like wiring (composition root) vs test wiring.
const rows = [], log = [];
const placeTest = makePlaceOrder({
  save: o => rows.push(o),
  notify: m => log.push(m),
  now: () => "2026-03-30T10:00",          // a fixed clock for the test
});
console.log(placeTest("tea", 2), placeTest("sugar", 0));
console.log("saved:", JSON.stringify(rows));
console.log("notified:", JSON.stringify(log));
console.log("eid price of 450:", eidDiscount(450), "| of 1200:", eidDiscount(1200));

// A closure can also hide state: n is reachable only through nextInvoice.
const nextInvoice = (() => { let n = 100; return () => "INV-" + (++n); })();
console.log(nextInvoice(), nextInvoice(), nextInvoice());

placed rejected
saved: [{"item":"tea","qty":2,"at":"2026-03-30T10:00"}]
notified: ["order tea x2 at 2026-03-30T10:00"]
eid price of 450: 405 | of 1200: 1080
INV-101 INV-102 INV-103

Class-ভিত্তিক DI-এর সাথে মিলিয়ে দেখুন: constructor-এর parameter ↔ বাইরের function-এর parameter; object-এর field ↔ closure-এর মনে রাখা variable; new ReportService(...) ↔ makePlaceOrder({...}). একই ধারণা, দুই রূপ। Haskell-এর মতো ভাষায় এর আরও আনুষ্ঠানিক রূপ আছে (যেমন Reader monad নামের একটি কৌশল, যা পরিবেশকে প্রতিটি function-এ নিঃশব্দে পৌঁছে দেয়); সেটি এই কোর্সের বিষয়ের বাইরে। একটি সতর্কতা: Python বা JavaScript-এ test-এর সময় module-এর ভেতরের function জোর করে বদলে দেওয়া যায় (Python-এ unittest.mock.patch, JavaScript test runner-এর module mocking) — এটি জরুরি অবস্থায় কাজের, কিন্তু DI-এর বিকল্প হিসেবে নিয়মিত ব্যবহার করলে নির্ভরতা আবার লুকানো থাকে, আর test ভাঙে কোডের ভেতরের নাম বদলালেই।

৭ · Inheritance-এর বদলে composition — গভীরে

পর্ব ২৬-এ composition over inheritance-এর নাম শুনেছেন — Gang of Four-এর ১৯৯৪ সালের বইয়ের পরামর্শ: “class inheritance-এর চেয়ে object composition-কে অগ্রাধিকার দিন।” DI আর composition একই মুদ্রার দুই পিঠ: composition মানে একটি object আরেকটিকে ধরে রেখে তাকে দিয়ে কাজ করায়; DI ঠিক করে সেই ধরে-রাখা object কোথা থেকে আসে। কিন্তু inheritance-এর বিরুদ্ধে আপত্তিটা আসলে কী? সবচেয়ে বিখ্যাত উত্তর একটি সমস্যার নাম — fragile base class.

ক্লাসিক উদাহরণটি Joshua Bloch-এর Effective Java বই থেকে জনপ্রিয় — সেখানে একটি HashSet-এর subclass কতগুলো উপাদান যোগ হলো তা গুনতে গিয়ে ভুল সংখ্যা পায়। নিচে একই ধারণা একটি কাল্পনিক মুদি-দোকানের বাজারের ঝুড়ি দিয়ে। Basket-এর দুটি method: add একটি জিনিস যোগ করে, add_all অনেকগুলো। একজন developer CountingBasket নামে subclass লিখলেন, যা গোনে কতগুলো জিনিস যোগ হয়েছে — দুটি method-ই override করে, দুই জায়গাতেই গুনে। Base-এর প্রথম সংস্করণে সব ঠিক। তারপর base-এর লেখক একটি “নিরীহ” পরিষ্কারের কাজ করলেন: add_all এখন নিজে list-এ না বসিয়ে self.add ডাকে — পুনরাবৃত্তি কমল, বাইরের আচরণ একই। নিচের stepper-এ দেখুন subclass-এ কী ঘটে।

1class CountingBasket(BasketV2):2    def add(self, item):3        self.count += 1; super().add(item)4    def add_all(self, items):5        self.count += len(items); super().add_all(items)6# BasketV2.add_all (base, new version):7        for it in items: self.add(it)8b.add("rice"); b.add_all(["dal", "oil", "salt"])

এবার আসল কোডে, আর তার সমাধান: CountingBasketC কোনো কিছু inherit করে না; একটি ঝুড়ি ধরে রাখে (composition) আর আসল কাজ তাকে দিয়ে করায় (delegation). ভেতরের ঝুড়ি তার নিজের add ডাকলেও সেটি ভেতরের ঝুড়ির add, গোনার মোড়কের নয় — তাই দুবার গোনার পথই নেই।

class Basket:                              # base class, version 1
    def __init__(self): self.items = []
    def add(self, item): self.items.append(item)
    def add_all(self, items):
        for it in items: self.items.append(it)   # v1: does NOT call add()

class BasketV2(Basket):                     # same base after a "harmless" cleanup
    def add_all(self, items):
        for it in items: self.add(it)            # v2: now reuses add()

def make_counting(base):                    # subclass written against the base
    class CountingBasket(base):
        def __init__(self): super().__init__(); self.count = 0
        def add(self, item): self.count += 1; super().add(item)
        def add_all(self, items): self.count += len(items); super().add_all(items)
    return CountingBasket

for base in (Basket, BasketV2):
    b = make_counting(base)()
    b.add("rice"); b.add_all(["dal", "oil", "salt"])
    print(f"{base.__name__:8} items={len(b.items)} count={b.count}")

class CountingBasketC:                      # the fix: composition + delegation
    def __init__(self, inner): self.inner = inner; self.count = 0
    def add(self, item): self.count += 1; self.inner.add(item)
    def add_all(self, items): self.count += len(items); self.inner.add_all(items)
    @property
    def items(self): return self.inner.items

for inner in (Basket(), BasketV2()):
    c = CountingBasketC(inner)
    c.add("rice"); c.add_all(["dal", "oil", "salt"])
    print(f"composed {type(inner).__name__:8} items={len(c.items)} count={c.count}")

Basket   items=4 count=4
BasketV2 items=4 count=7
composed Basket   items=4 count=4
composed BasketV2 items=4 count=4

Inheritance কখন ঠিক

Composition-এর পক্ষে বলা মানে inheritance নিষিদ্ধ নয়। প্রশ্নটি হলো সম্পর্কের ধরন:

Bloch-এর পরামর্শটি মনে রাখার মতো: base class হয় inheritance-এর জন্য নকশা করে documentation লিখুন (কোন method কোন method-কে ডাকে, তা চুক্তির অংশ করে), নয়তো inheritance নিষেধ করুন (Java-তে final, Kotlin-এ class ডিফল্টভাবেই final). পর্ব ৩৫-এর template method এই প্রথম পথের উদাহরণ: base জেনেশুনে নির্দিষ্ট hook দেয় আর ডাকার ক্রম ঘোষণা করে। একই সমস্যার composition-রূপ হলো strategy — hook-গুলো আলাদা object হয়ে constructor-এ আসে।

Mixin, trait আর delegation — মাঝামাঝি পথ

Mixin হলো একটি ছোট class, যা একা ব্যবহারের জন্য নয়, অন্য class-এ একটি ক্ষমতা “মিশিয়ে” দেওয়ার জন্য — যেমন Python-এ class Invoice(JsonMixin, Base), যেখানে JsonMixin শুধু to_json() দেয়। Python-এ এটি multiple inheritance দিয়ে হয়, তাই fragile base class আর method-এর নাম-সংঘাতের ঝুঁকি থেকেই যায়; ভালো mixin ছোট, অবস্থাহীন আর অন্য method-এর ভেতরের ক্রমের ওপর নির্ভর করে না। Trait একই উদ্দেশ্যের আরও নিয়ন্ত্রিত রূপ — Schärli ও সহকর্মীদের ২০০৩ সালের ECOOP গবেষণাপত্র থেকে প্রচলিত বলে উল্লেখ করা হয় — যেখানে নাম-সংঘাত হলে ভাষা চুপচাপ একটি বেছে নেয় না, আপনাকে স্পষ্ট সমাধান দিতে হয়। লক্ষ করুন, “trait” শব্দটি ভাষাভেদে ভিন্ন জিনিস বোঝায়: PHP আর Scala-র trait কোড মেশায়, আর Rust-এর trait অনেকটা interface-এর মতো — Rust-এ class inheritance-ই নেই, Go-তেও নেই (Go-তে struct embedding দিয়ে delegation-এর মতো ব্যবস্থা)। কিছু ভাষা delegation-কে সহজ করে — যেমন Kotlin-এ by শব্দ দিয়ে একটি interface-এর সব method আরেকটি object-এ forward করা যায়, যা CountingBasketC-এর হাতে লেখা forward-এর কাজ বাঁচায়।

৮ · AI-এর যুগে DI আর composition

AI-কে “এই কোডে dependency injection যোগ করো” বললে সে প্রায়ই অনেক বেশি করে — অথবা ভুল জিনিসটি করে। কিছু সাধারণ ভুল আর ধরার উপায়:

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

• Business class-গুলোর ভেতরে আর কোনো লুকানো new, global বা Locator.get() নেই — নিজে খুঁজে দেখেছি
• সব object তৈরি আর জোড়া একটি composition root-এ; test-গুলোর নিজস্ব ছোট জোড়া আছে
• প্রতিটি singleton-এর অবস্থা ভাগ করা নিরাপদ, আর তার কোনো dependency তার চেয়ে কম আয়ুর নয়
• Container বা framework-এর প্রতিটি API আমার version-এর official documentation-এ মিলিয়েছি
• নতুন test ইচ্ছা করে ভাঙা কোডে চালিয়ে দেখেছি যে সত্যিই ফেল করে
• বদলগুলো আলাদা branch-এ ছোট commit-এ, pull request হিসেবে review করেছি (পর্ব ১৬, ১৮)
• Prompt-এ কোনো secret, connection string বা গ্রাহকের তথ্য দিইনি; AI-এর দেওয়া কোডের উৎস বা licence নিয়ে সন্দেহ হলে যাচাই করেছি