inheritance বনাম composition — কখন উত্তরাধিকার, কখন অংশ দিয়ে গড়া

১ · দুটি সম্পর্ক — “এটি একটি …” আর “এর একটি … আছে”

পর্ব ২৯-এ আপনি class বানিয়েছেন — একটি ছাঁচ, যা থেকে অনেক instance তৈরি হয়, প্রত্যেকের নিজের attribute আর সবার জন্য একই method. পর্ব ৩০-এ দেখেছেন __repr__, __eq__-এর মতো dunder method দিয়ে নিজের class-কে Python-এর ভাষার সাথে মিশিয়ে দেওয়া। কিন্তু বাস্তব প্রোগ্রামে class একা থাকে না। একটি ব্যাংক সফটওয়্যারে থাকে সাধারণ Account, সঞ্চয়ী Account, চলতি Account; একটি অনলাইন দোকানে থাকে Order, Customer, পণ্য, ডেলিভারি, পেমেন্ট। প্রশ্ন হলো: এই class-গুলো একে অপরের সাথে কীভাবে যুক্ত হবে?

উত্তর দুই রকম, আর পুরো পর্ব এই দুইয়ের পার্থক্য নিয়ে:

শুরুতেই পর্বের মূল উপদেশটি বলে রাখি, যাতে পড়ার সময় মাথায় থাকে: is-a যদি সত্যিই, সব পরিস্থিতিতে সত্য হয়, তবেই inheritance. বাকি সব ক্ষেত্রে composition. আর Python-এ অনেক সময় দুটোর কোনোটিই লাগে না — পর্ব ০৬-এ দেখা duck typing-এর কারণে একই নামের method থাকলেই বিভিন্ন object একই জায়গায় কাজ করে, কোনো সম্পর্ক ছাড়াই। এই তিনটি পথ একে একে দেখব।

২ · Subclass বানানো — উত্তরাধিকারে পাওয়া আর override করা

Python-এ inheritance-এর ব্যাকরণ এক লাইনের: class-এর নামের পরে বন্ধনীতে বাবার নাম। যে class থেকে inherit করা হয় তাকে বলে base class (parent, superclass), আর নতুনটিকে subclass (child, derived class).

class Account:
    def __init__(self, owner, balance=0):
        self.owner = owner
        self.balance = balance

    def deposit(self, amount):
        self.balance += amount

    def withdraw(self, amount):
        if amount > self.balance:
            raise ValueError("ব্যালান্স যথেষ্ট নয়")
        self.balance -= amount

class SavingsAccount(Account):      # SavingsAccount একটি Account
    def add_interest(self, rate=0.05):
        self.deposit(round(self.balance * rate))

SavingsAccount-এর ভেতরে মাত্র একটি method লেখা আছে, তবু savings = SavingsAccount("রিনা", 4000) লিখলে __init__ চলে, savings.deposit(500) চলে, savings.withdraw(100) চলে — সব এসেছে Account থেকে। এটাই উত্তরাধিকার। আর add_interest-এর ভেতরে self.deposit(...) লক্ষ করুন: subclass নিজের method থেকে বাবার method স্বাভাবিকভাবেই ডাকতে পারে, কারণ self তো একটি Account-ও।

একটি কথা এখনই জেনে রাখুন: Python 3-এ প্রতিটি class শেষ পর্যন্ত object থেকে আসে। class Account: লেখা আর class Account(object): লেখা একই। __repr__, __eq__-এর মতো যে dunder method আপনি না লিখলেও পাওয়া যায় (পর্ব ৩০), সেগুলোর ডিফল্ট রূপ আসে এই object থেকেই।

“উত্তরাধিকার” আসলে কী — কপি নয়, খোঁজা

অনেকে ভাবেন subclass তৈরির সময় বাবার method-গুলো তার ভেতরে কপি হয়। তা নয়। SavingsAccount-এর নিজের খাতায় (SavingsAccount.__dict__) শুধু add_interest আছে। savings.withdraw লিখলে Python একটি খোঁজা চালায় — প্রথমে instance-এর নিজের খাতায়, তারপর তার class-এ, তারপর বাবার class-এ, এভাবে উপরে — যেখানে প্রথম পায়, সেটাই ব্যবহার করে। পর্ব ২০-এর LEGB-র মতোই, শুধু এবার নামের বদলে attribute. এই খোঁজার ক্রমকে বলে method resolution order বা MRO. “পরে” চেপে savings.withdraw(6000)-এর খোঁজা দেখুন (ডায়াগ্রামে অংশ ৩-এর runnable প্রোগ্রামের পূর্ণ class-গুলো ধরা হয়েছে, যেখানে Account-এ একটি limit method আর SavingsAccount-এ rate আছে):

{'owner': 'রিনা', 'balance': 4200, 'rate': 0.05}

'withdraw' এখানে আছে?  না  → পরের জায়গায় চলো

__init__       ← SavingsAccount নিজে লিখেছে
add_interest   ← SavingsAccount নিজে লিখেছে

'withdraw' এখানে আছে?  না  → MRO-র পরের class

__init__
limit
withdraw   ← পাওয়া গেল! খোঁজা এখানেই শেষ

savings.withdraw  →  bound method (self = savings)
ডাক:  Account.withdraw(savings, 6000)

self = savings  →  খোঁজা শুরু savings থেকে, Account থেকে নয়!
  savings.__dict__        limit? না
  SavingsAccount          limit? না
  Account                 limit? হ্যাঁ → balance (4200)

self = current (CurrentAccount) হলে:
  current.__dict__        limit? না
  CurrentAccount          limit? হ্যাঁ → balance + overdraft
  Account.limit পর্যন্ত যাওয়াই হয় না

withdraw আগেই পাওয়া গেছে, তাই object পর্যন্ত আসতে হয়নি।

কোথাও না পেলে (যেমন savings.fly()):
AttributeError: 'SavingsAccount' object has no attribute 'fly'

SavingsAccount.__mro__ =
(SavingsAccount, Account, object)

Override — বাবার method বদলে দেওয়া

Subclass যদি বাবার একই নামের একটি method নিজে লেখে, খোঁজার সময় সেটি আগে পাওয়া যায় — বাবারটি ঢাকা পড়ে। একে বলে override. চলতি হিসাবের (current account) কথা ভাবুন: সেখানে ব্যাংক একটি overdraft সুবিধা দেয় — ব্যালান্সের চেয়ে কিছু বেশি তোলা যায়। তাই “কত পর্যন্ত তোলা যাবে” নিয়মটি আলাদা। পুরো withdraw আবার না লিখে শুধু সীমার নিয়মটি override করাই পরিষ্কার নকশা: বাবা withdraw-এ self.limit() ডাকে, আর CurrentAccount নিজের limit দেয়। বাবা ঠিক করে দিল কাজের কাঠামো, সন্তান বদলাল একটি ধাপ।

৩ · super() — বাবাকে ডাকা, আর __init__ বাড়ানো

Override মানে সবসময় পুরোপুরি বদলে দেওয়া নয়। প্রায়ই আপনি চান বাবার কাজটুকু হোক, তারপর নিজের অংশ যোগ হোক। সবচেয়ে সাধারণ উদাহরণ __init__. SavingsAccount-এর একটি সুদের হার দরকার, তাই তার নিজের __init__ লাগবে — কিন্তু owner আর balance বসানোর কাজ তো Account.__init__ আগেই করে। সেটি আবার লেখা মানে কোড নকল, আর বাবার নিয়ম বদলালে দুই জায়গায় বদলাতে হবে।

সমাধান super(): “MRO-তে আমার পরের class-এর এই method-টি ডাকো, আর self হিসেবে এই object-টিই দাও”.

class SavingsAccount(Account):
    def __init__(self, owner, balance=0, rate=0.05):
        super().__init__(owner, balance)    # বাবা বসাবে owner, balance
        self.rate = rate                    # নিজের অংশ

এভাবে __init__-কে “বাড়ানো” (extend) হলো: বাবার কাজ আগে, নিজের কাজ পরে। এবার ধাপে ধাপে দেখুন একটি CurrentAccount object কীভাবে দুই তলায় তৈরি হয়:

1class Account:2    def __init__(self, owner, balance=0):3        self.owner = owner4        self.balance = balance56class CurrentAccount(Account):7    def __init__(self, owner, balance=0, overdraft=5000):8        super().__init__(owner, balance)9        self.overdraft = overdraft1011current = CurrentAccount("করিম", 2000)12print(current.owner, current.balance, current.overdraft)

কেন Account.__init__(self, ...) নয়?

পুরোনো কোডে প্রায়ই দেখবেন Account.__init__(self, owner, balance) — বাবার নাম ধরে সরাসরি ডাকা। এক বাবা থাকলে এটি কাজ করে, কিন্তু তিনটি দুর্বলতা আছে। এক, বাবার নাম কোডের ভেতরে গেঁথে গেল: কাল যদি Account আর CurrentAccount-এর মাঝে একটি BankAccount class বসান, প্রতিটি সরাসরি ডাক খুঁজে খুঁজে বদলাতে হবে, আর একটি ভুলে গেলে মাঝের class-এর __init__ নিঃশব্দে বাদ পড়বে। দুই, self হাতে দিতে হয় — ভুলে গেলে অদ্ভুত error. তিন, আর সবচেয়ে গুরুত্বপূর্ণ: একাধিক বাবা থাকলে (অংশ ৫) সরাসরি ডাক একই base class-কে দুবার চালিয়ে দিতে পারে। super() MRO মেনে চলে, তাই প্রতিটি class ঠিক একবার আসে।

Python 2-তে super লিখতে হতো এভাবে: super(CurrentAccount, self).__init__(...). Python 3.0 থেকে বন্ধনী খালি রাখা যায় — compiler নিজে বুঝে নেয় কোন class-এর ভেতরে আছেন আর self কে।

যেকোনো method-এ super() — বাবার কাজ রেখে নিজেরটা যোগ

super() শুধু __init__-এর জন্য নয়। ধরুন সঞ্চয়ী হিসাবে মাসে একটি নির্দিষ্ট সংখ্যার বেশি টাকা তোলা যায় না। withdraw override করে প্রথমে সেই গণনা যাচাই করুন, তারপর return super().withdraw(amount) — ব্যালান্স যাচাই আর কাটার আসল কাজ বাবার কোডই করবে। নিয়মটি মনে রাখুন: override করলে নিজেকে জিজ্ঞেস করুন, বাবার কাজটি কি বাদ দিতে চাই, নাকি তার আগে-পরে কিছু যোগ করতে চাই? দ্বিতীয়টি হলে super().

এবার প্রথম runnable প্রোগ্রাম। এখানে Account-এর withdraw একটি কাঠামো, যা self.limit() ডাকে; CurrentAccount শুধু limit override করেছে। চালানোর আগে অনুমান করুন — রিনার সঞ্চয়ী হিসাবে সুদের পরে কত হবে, আর দুজনের ৬০০০ টাকা তোলার চেষ্টার ফল কী:

class Account:
    def __init__(self, owner, balance=0):
        self.owner, self.balance = owner, balance

    def limit(self):
        return self.balance

    def withdraw(self, amount):
        if amount > self.limit():
            return f"{self.owner}: ব্যর্থ, সীমা {self.limit()}"
        self.balance -= amount
        return f"{self.owner}: বাকি {self.balance}"

class SavingsAccount(Account):
    def __init__(self, owner, balance=0, rate=0.05):
        super().__init__(owner, balance)
        self.rate = rate

    def add_interest(self):
        self.balance += round(self.balance * self.rate)

class CurrentAccount(Account):
    def __init__(self, owner, balance=0, overdraft=5000):
        super().__init__(owner, balance)
        self.overdraft = overdraft

    def limit(self):                    # override
        return self.balance + self.overdraft

savings, current = SavingsAccount("রিনা", 4000), CurrentAccount("করিম", 2000)
savings.add_interest()
for acc in [savings, current]:
    print(acc.withdraw(6000))
print(" → ".join(k.__name__ for k in SavingsAccount.__mro__))
print(isinstance(current, Account), issubclass(bool, int))

৪ · Polymorphism — একই ডাক, ভিন্ন আচরণ; আর duck typing

উপরের লুপটিতে যা ঘটল তার একটি নাম আছে: polymorphism (গ্রিক শব্দ, “বহু রূপ”)। একই কোড — acc.withdraw(6000) — বিভিন্ন type-এর object-এ চলছে, আর প্রতিটি object নিজের মতো সাড়া দিচ্ছে। কোন method চলবে তা ঠিক হয় চালানোর সময়, object-টির আসল class দেখে। একে বলে dynamic dispatch.

একটি বাংলাদেশি উদাহরণে দেখা যাক। একটি অনলাইন দোকানে ক্রেতা bKash, Nagad বা কার্ডে টাকা দিতে পারেন, আর প্রতিটি পদ্ধতির চার্জ আলাদা (এখানের হারগুলো শুধু উদাহরণ, আসল হার নয়)। Polymorphism ছাড়া লেখা কোড দেখতে এমন হয়:

def fee(payment, amount):
    if isinstance(payment, Bkash):
        return round(amount * 0.015)
    elif isinstance(payment, Nagad):
        return round(amount * 0.012)
    elif isinstance(payment, Card):
        return 0
    raise TypeError("অচেনা পেমেন্ট")

কাজ চলে, কিন্তু নতুন একটি পদ্ধতি (ধরুন Rocket) যোগ করলে এই ফাংশন খুলে নতুন elif লিখতে হবে — আর একই ধরনের if-শৃঙ্খল যদি দশ জায়গায় থাকে (চার্জ, রসিদের লেখা, রিফান্ডের নিয়ম), দশ জায়গাতেই। একটি ভুলে গেলে বাগ। Polymorphism দিয়ে দায়িত্বটি উল্টে দিন: প্রতিটি পেমেন্ট নিজের চার্জ নিজে জানে.

class Payment:
    def fee(self, amount):
        raise NotImplementedError("প্রতিটি পেমেন্টকে fee() লিখতে হবে")

class Bkash(Payment):
    def fee(self, amount):
        return round(amount * 0.015)

class Card(Payment):
    def fee(self, amount):
        return 0

for p in [Bkash(), Card()]:
    print(type(p).__name__, p.fee(1000))     # Bkash 15, Card 0

এখন Rocket যোগ করতে শুধু একটি নতুন class — কোনো পুরোনো কোড ছোঁয়া লাগে না। Design principle-এর ভাষায় একে বলে Open/Closed নীতি: নতুন কিছু যোগের জন্য খোলা, পুরোনো কোড বদলানোর জন্য বন্ধ।

raise NotImplementedError — “এটি সন্তানদের কাজ”

Payment.fee-এর ভেতরে কোনো হিসাব নেই — আছে শুধু NotImplementedError. এর মানে: “Payment নিজে কোনো আসল পেমেন্ট নয়; প্রতিটি subclass-কে fee() লিখতে হবে”. কেউ ভুলে গেলে error আসবে — কিন্তু ডাকার সময়, object তৈরির সময় নয়। আরও কড়া ব্যবস্থা আছে: abc module-এর abstract base class (ABC) আর @abstractmethod, যা নিয়ম না মানা subclass-এর object তৈরিই করতে দেয় না। সেটির পুরো গল্প পর্ব ৩৩-এ। (একটি ছোট সতর্কতা: NotImplementedError একটি exception; এর সাথে প্রায় একই নামের NotImplemented আলাদা জিনিস — পর্ব ৩০-এর __eq__, __add__-এর মতো operator method যে বিশেষ মান ফেরত দেয়।)

Duck typing — base class ছাড়াই polymorphism

এবার Python-এর একটি বিশেষত্ব। Java বা C++-এ উপরের লুপ চালাতে হলে Bkash আর Card-কে একই base class (বা interface) থেকে আসতেই হবে। Python-এ তা লাগে না। লুপটি শুধু p.fee(1000) ডাকে — p-এর class কী, তার বাবা কে, Python তা জিজ্ঞেস করে না; শুধু দেখে fee নামের attribute আছে কি না। Payment base class পুরোপুরি মুছে দিলেও লুপ একইভাবে চলবে।

এর ফল গভীর: Python-এ polymorphism পেতে inheritance লাগে না। Inheritance-এর তখন একমাত্র কাজ থাকে সত্যিকারের ভাগ করা আচরণ বা প্রতিশ্রুতি দেওয়া। আর “কোন method থাকতে হবে” লিখিত চুক্তি চাইলে Python দেয় typing.Protocol — inheritance ছাড়াই type checker-কে চুক্তিটি জানানো। ABC বনাম Protocol বনাম খাঁটি duck typing — পর্ব ৩৩-এর বিষয়।

isinstance আর issubclass — কখন ঠিক, কখন গন্ধ

isinstance(obj, Cls) জানায় obj সেই class বা তার কোনো subclass-এর object কি না; issubclass(A, B) জানায় class A class B থেকে এসেছে কি না। দুটিই inheritance মানে: isinstance(current, Account) হলো True, যদিও type(current) হলো CurrentAccount. তাই type(x) == Account লিখবেন না — subclass-এর object বাদ পড়বে। (দ্বিতীয় argument-এ tuple দেওয়া যায়, আর Python 3.10 থেকে isinstance(x, int | float)-ও লেখা যায়।)

কিন্তু উপরের fee_bad.py-এর মতো isinstance-এর লম্বা শৃঙ্খল সাধারণত একটি code smell — লক্ষণ যে আচরণটি ভুল জায়গায় আছে; object-কে জিজ্ঞেস করার বদলে বাইরে থেকে তার পরিচয় যাচাই হচ্ছে। তবে isinstance-এর সৎ ব্যবহারও আছে: বাইরে থেকে আসা ডেটা যাচাই (JSON থেকে পাওয়া মান সত্যিই int কি না), এমন ফাংশন যা ইচ্ছা করেই একটি string আর একটি list-কে আলাদাভাবে সামলায়, বা পর্ব ৩০-এর __eq__-এ অন্য type-এর সাথে তুলনা এড়ানো। নিয়ম: ডেটার সীমানায় isinstance ঠিক আছে; ব্যবসার যুক্তির ভেতরে isinstance-শৃঙ্খল দেখলে polymorphism ভাবুন. Python 3.10-এর match-এর class pattern (পর্ব ১১) একই সতর্কতা মানে — ডেটার আকার মেলাতে চমৎকার, কিন্তু আচরণ বাছাইয়ের জন্য method-ই ভালো।

৫ · একাধিক বাবা — multiple inheritance, diamond আর MRO

Python একটি class-কে একাধিক বাবা থেকে আসতে দেয় — একে বলে multiple inheritance: class Copier(Printer, Scanner):. একটি ফটোকপি মেশিন একটি প্রিন্টারও, একটি স্ক্যানারও। শুনতে স্বাভাবিক, কিন্তু একটি প্রশ্ন তৈরি হয়: দুই বাবারই যদি একই নামের method থাকে, কোনটি চলবে? আর দুই বাবাই যদি একই দাদা (Device) থেকে আসে?

Python এই প্রশ্নের উত্তর দেয় class তৈরির মুহূর্তেই: পুরো গাছটিকে একটি সরল সারিতে সাজিয়ে ফেলে — MRO. সাজানোর নিয়মটির নাম C3 linearization. এর তিনটি শর্ত সহজ ভাষায়:

• সন্তান বাবার আগে: প্রতিটি class তার সব বাবার আগে আসবে (Copier আগে, Printer পরে; Printer আগে, Device পরে)।
• বাবাদের লেখার ক্রম রক্ষা: (Printer, Scanner) লিখেছেন, তাই Printer আসবে Scanner-এর আগে।
• প্রতিটি class একবার, আর বাবাদের নিজেদের সারির ক্রমও রক্ষা (একে বলে monotonic) — কোনো subclass তার বাবার MRO-র ক্রম উল্টে দিতে পারবে না।

ফল: Copier.__mro__ = (Copier, Printer, Scanner, Device, object). Device আসে একবার, আর দুই বাবার পরে। শর্তগুলো মেলানো অসম্ভব হলে Python class বানাতেই দেয় না — যেমন class X(Device, Printer) লিখলে (বাবাকে সন্তানের আগে বসালে) আসে TypeError: Cannot create a consistent method resolution order (MRO) for bases Device, Printer.

Cooperative super() — “বাবা” নয়, “সারির পরের জন”

এখানে এসে super()-এর আসল অর্থ পরিষ্কার হয়। super() মানে “আমার বাবা” নয়; মানে “এই object-এর MRO-তে আমার ঠিক পরের class”. এক বাবা থাকলে দুটো একই জিনিস। কিন্তু diamond-এ Printer-এর ভেতরের super() একটি Copier object-এর জন্য ডাকে Scanner-কে — Printer যার অস্তিত্বই জানে না! ধাপে ধাপে দেখুন:

1class Device:2    def __init__(self):3        print("Device")4class Printer(Device):5    def __init__(self):6        print("Printer"); super().__init__()7class Scanner(Device):8    def __init__(self):9        print("Scanner"); super().__init__()10class Copier(Printer, Scanner):11    def __init__(self):12        print("Copier"); super().__init__()1314Copier()

Cooperative নকশায় আরেকটি সমস্যা থাকে: ভিন্ন __init__-এর ভিন্ন argument লাগলে কে কী পাবে? প্রচলিত কৌশল হলো প্রতিটি __init__ নিজের দরকারি argument নাম ধরে নেবে, বাকিগুলো **kwargs-এ জমিয়ে (পর্ব ২০) super().__init__(**kwargs)-এ পাঠিয়ে দেবে। সারির শেষে পৌঁছানোর আগে সব argument কেউ না কেউ নিয়ে নেবে। Raymond Hettinger তাঁর বিখ্যাত লেখা “Super considered super!”-এ এই ধরনটি বিস্তারিত দেখিয়েছেন (নিচের ভাবনার প্রশ্ন ৪)।

Mixin — ছোট, মেশানো যায় এমন আচরণ

বাস্তবে multiple inheritance-এর সবচেয়ে নিরাপদ ও প্রচলিত ব্যবহার হলো mixin: একটি ছোট class, যা একটি মাত্র বাড়তি ক্ষমতা দেয়, নিজে একা ব্যবহারের জন্য নয়, আর সাধারণত নিজের কোনো __init__ বা অবস্থা রাখে না। যেমন:

import json

class JsonMixin:
    def to_json(self):
        return json.dumps(self.__dict__, ensure_ascii=False)

class ReprMixin:
    def __repr__(self):
        fields = ", ".join(f"{k}={v!r}" for k, v in self.__dict__.items())
        return f"{type(self).__name__}({fields})"

class Customer(JsonMixin, ReprMixin):
    def __init__(self, name, phone):
        self.name, self.phone = name, phone

c = Customer("রিনা", "01700000000")
print(c)              # Customer(name='রিনা', phone='01700000000')
print(c.to_json())    # {"name": "রিনা", "phone": "01700000000"}

JsonMixin যেকোনো class-কে JSON-এ রূপান্তরের ক্ষমতা দেয়, ReprMixin দেয় পড়ার মতো __repr__ — যেকোনো class-এ মিশিয়ে নিন, অনেকটা চায়ে চিনি বা আদা মেশানোর মতো। বাস্তবে Python-এর standard library-তে socketserver.ThreadingMixIn আছে, আর Django-তে LoginRequiredMixin-এর মতো অনেক mixin. প্রচলিত রীতি: নামের শেষে Mixin, আর class লেখার সময় mixin-গুলো বাঁয়ে, আসল base class সবার ডানে — যাতে MRO-তে mixin-এর method আগে পাওয়া যায়।

৬ · কখন is-a আসলে মিথ্যা — Liskov নীতি আর built-in থেকে inherit করা

অংশ ১-এর প্রতিশ্রুতিটি মনে করুন: “যেখানে বাবাকে ব্যবহার করা যায়, সেখানে আমাকেও করা যাবে।” এই কথাটিরই আনুষ্ঠানিক নাম Liskov substitution principle (LSP) — Barbara Liskov-এর নামে, যিনি ১৯৮৭ সালের একটি বক্তৃতায় ধারণাটি তুলে ধরেন। বিখ্যাত উদাহরণ: গণিতে প্রতিটি বর্গ একটি আয়তক্ষেত্র। তাহলে class Square(Rectangle) লেখা কি ঠিক?

class Rectangle:
    def __init__(self, w, h):
        self.w, self.h = w, h
    def set_width(self, w):
        self.w = w
    def area(self):
        return self.w * self.h

class Square(Rectangle):
    def __init__(self, side):
        super().__init__(side, side)
    def set_width(self, w):          # বর্গ রাখতে উচ্চতাও বদলাতে হয়
        self.w = self.h = w

def stretch(r: Rectangle):
    r.set_width(10)
    return r.area()                  # যে Rectangle(2, 5) দিলে 50 আশা করে

stretch(Rectangle(2, 5)) দেয় 50 — প্রস্থ ১০, উচ্চতা ৫. কিন্তু stretch(Square(5)) দেয় 100, কারণ বর্গ থাকতে গিয়ে উচ্চতাও বদলে গেছে। যে ফাংশন একটি Rectangle-এর জন্য লেখা, সে একটি Square পেয়ে ভুল ফল দিল। গণিতের is-a সত্য, কিন্তু আচরণের is-a মিথ্যা — কারণ একটি “প্রস্থ বদলানো যায় এমন আয়তক্ষেত্র” যা প্রতিশ্রুতি দেয়, বর্গ তা রাখতে পারে না। সমাধান: Square-কে Rectangle-এর সন্তান না বানানো (দুটি আলাদা class, দরকারে একটি সাধারণ area() duck typing দিয়ে), অথবা object-গুলোকে immutable রাখা — তখন “প্রস্থ বদলানো” আচরণটিই থাকে না। SOLID নীতির পুরো আলোচনা, C++-এর উদাহরণসহ, দেখুন C++ কোর্সের design principles পর্বে.

dict বা list থেকে inherit করা — একটি সূক্ষ্ম ফাঁদ

Python 2.2 থেকে built-in type থেকেও inherit করা যায়: class PhoneBook(dict):. শুনতে দারুণ — সব dict method বিনা পরিশ্রমে। ধরুন আপনি চান প্রতিটি নাম বড় হাতের অক্ষরে জমা হোক, তাই __setitem__ override করলেন। book["rina"] = "017…" ঠিক কাজ করবে। কিন্তু PhoneBook(rina="017…") বা book.update(karim="018…") — এগুলো আপনার __setitem__ ডাকে না! CPython-এর dict C-তে লেখা, আর গতির জন্য তার __init__, update, setdefault সরাসরি ভেতরের তথ্য বদলায়, আপনার override করা method ঘুরে নয়। একইভাবে book.get(k) আপনার override করা __getitem__ ব্যবহার করে না, আর book.copy() ফেরত দেয় সাধারণ dict, PhoneBook নয়। ফল: একই dict-এ কিছু চাবি বড় হাতের, কিছু ছোট হাতের — নিঃশব্দ বাগ।

সমাধান collections module-এর UserDict (আর UserList, UserString). এগুলো Python-এ লেখা wrapper — ভেতরে একটি সাধারণ dict রাখে (self.data), আর update, constructor সহ সব পথ আপনার __setitem__ ঘুরে যায়। অর্থাৎ এগুলো ভেতরে আসলে composition! আরও সরল পথ: dict-কে inherit না করে নিজের class-এ একটি dict attribute রাখুন, আর শুধু যে কয়েকটি method দরকার সেগুলো দিন। নিয়ম: built-in-এর আচরণ বদলাতে চাইলে UserDict/UserList বা composition; শুধু নতুন method যোগ করতে চাইলে (কিছু বদলাতে নয়) built-in থেকে inherit করা মোটামুটি নিরাপদ.

৭ · Composition আর delegation — অংশ দিয়ে গড়া, অংশ অদলবদল

এবার অন্য পথ। একটি অনলাইন অর্ডারের কথা ভাবুন। অর্ডারে আছে একজন ক্রেতা, কয়েকটি পণ্য, একটি ডেলিভারি পদ্ধতি, একটি পেমেন্ট পদ্ধতি, আর অর্ডার নিশ্চিত হলে ক্রেতাকে জানানোর একটি উপায় (SMS বা Email). অর্ডার কি একটি Customer? না। একটি Payment? না। অর্ডারের এগুলো আছে — has-a. তাই Order এগুলোকে নিজের attribute হিসেবে রাখবে: এটাই composition.

আর অর্ডার যখন চার্জ জানতে চায়, সে নিজে হিসাব করে না — পেমেন্ট object-কে জিজ্ঞেস করে: self.payment.fee(subtotal). নিজের কাজের একটি অংশ অন্য object-কে দিয়ে করিয়ে নেওয়াকে বলে delegation. বাংলায় বললে, অর্ডার একজন ম্যানেজার: হিসাবের কাজ হিসাবরক্ষককে, খবর পাঠানোর কাজ পিয়নকে দেয়।

Composition-এর সবচেয়ে বড় সুবিধা: অংশগুলো চালানোর সময় অদলবদল করা যায়। একই Order class — কোনো subclass ছাড়াই — একবার bKash আর SMS দিয়ে, আরেকবার Card আর Email দিয়ে চলতে পারে। এই কৌশলের একটি নাম আছে: strategy pattern — একটি কাজের “কীভাবে” অংশটি আলাদা object বা ফাংশনে রেখে বাইরে থেকে দেওয়া। Python-এ ফাংশনও object (first-class function, পর্ব ১৩), তাই strategy হিসেবে অনেক সময় একটি সাধারণ ফাংশনই যথেষ্ট — নিচে notifier হিসেবে sms আর email শুধু দুটি ফাংশন।

class Bkash:
    name = "bKash"
    def fee(self, amount):
        return round(amount * 0.015)

class Card:
    name = "Card"
    def fee(self, amount):
        return 0

def sms(to, text):
    print(f"SMS → {to}: {text}")

def email(to, text):
    print(f"Email → {to}: {text}")

class Order:
    def __init__(self, customer, items, delivery, payment, notify):
        self.customer, self.items, self.delivery = customer, items, delivery
        self.payment, self.notify = payment, notify

    def checkout(self):
        subtotal = sum(price * qty for price, qty in self.items.values())
        total = subtotal + self.delivery + self.payment.fee(subtotal)
        self.notify(self.customer, f"{self.payment.name}-এ মোট {total} টাকা")

items = {"চাল": (70, 5), "ডাল": (130, 2)}
Order("রিনা", items, 60, Bkash(), sms).checkout()
Order("রিনা", items, 60, Card(), email).checkout()

লক্ষ করুন, এখানে ডেলিভারি শুধু একটি সংখ্যা (৬০)। প্রয়োজন বাড়লে — ঢাকার ভেতরে ও বাইরে আলাদা চার্জ, ওজন অনুযায়ী চার্জ — এটিকেও একটি Delivery object বানিয়ে self.delivery.charge(items) দিয়ে delegate করবেন। Composition-এর এই ধাপে ধাপে বাড়ানো সহজ: একটি অংশ জটিল হলে শুধু সেই অংশটি নিজের class পায়, বাকি নকশা অক্ষত থাকে। (পর্ব ৩২-এ দেখবেন @dataclass দিয়ে এই ধরনের ছোট “অংশ” class এক লাইনে বানানো যায়।)

Delegation-এর বিস্তার — কতটা আড়াল করবেন

Composition-এ একটি প্রশ্ন আসে: বাইরের কোড কি order.payment.fee(x) লিখবে, নাকি order.fee()? দ্বিতীয়টি সাধারণত ভালো — Order একটি ছোট method দেয়, যা ভেতরে delegate করে। এতে বাইরের কোড Order-এর ভেতরের গঠন জানে না; কাল পেমেন্ট অংশের নাম বা গঠন বদলালেও বাইরের কোড ভাঙে না। (একে কখনো “Law of Demeter” বলে — “শুধু নিজের কাছের বন্ধুদের সাথে কথা বলো”।) Python-এ অনেক method একবারে delegate করতে __getattr__ ব্যবহার করা যায় — যে attribute নিজের কাছে পাওয়া যায় না, সেটি ভেতরের object-এ খোঁজা — তবে এটি জাদুর মতো আড়াল তৈরি করে, editor-এর auto-complete কাজ করে না; কয়েকটি method হলে হাতে লেখাই পরিষ্কার।

৮ · গভীর inheritance-গাছ ভেঙে composition — আর কোনটি কখন

বাস্তব প্রজেক্টে সমস্যা সাধারণত শুরু হয় ভালো উদ্দেশ্য নিয়ে। একটি নোটিফিকেশন সিস্টেম: প্রথমে Notifier, তা থেকে SMSNotifier আর EmailNotifier. তারপর নতুন চাহিদা — জরুরি বার্তা ব্যর্থ হলে তিনবার চেষ্টা; তারপর — সব বার্তার লগ রাখা। প্রতিটি নতুন চাহিদায় একটি নতুন subclass যোগ করলে কী হয়, দেখুন:

Notifier
├── SMSNotifier       send() → SMS gateway
└── EmailNotifier     send() → SMTP

এখানে inheritance যুক্তিসঙ্গত: SMSNotifier একটি Notifier.

Notifier
├── SMSNotifier
│   ├── RetrySMSNotifier
│   ├── LoggedSMSNotifier
│   └── RetryLoggedSMSNotifier     ← কার কাছ থেকে inherit?
└── EmailNotifier
    ├── RetryEmailNotifier
    ├── LoggedEmailNotifier
    └── RetryLoggedEmailNotifier

WhatsApp যোগ করলে আরও ৪টি class.  retry-র নিয়ম বদলালে ৪ জায়গায়।

১. কোন পথে?        SMS · Email · WhatsApp        → channel
২. কতবার চেষ্টা?    ১ বার · ৩ বার                → retries (সংখ্যা)
৩. লগ রাখব?        হ্যাঁ · না                    → logger (ফাংশন বা None)

৩ × ২ × ২ = ১২টি মিশ্রণ — inheritance দিয়ে ১২টি class,
composition দিয়ে ৩টি channel class + ১টি Notifier.

class Notifier:
    def __init__(self, channel, retries=1, logger=None):
        self.channel, self.retries, self.logger = channel, retries, logger
    def send(self, to, text):
        for _ in range(self.retries):
            if self.channel.send(to, text):      # delegation
                break
        if self.logger:
            self.logger(f"{to}: {text}")

urgent = Notifier(SMS(), retries=3, logger=print)
weekly = Notifier(Email())
ব্যবহারকারী পছন্দ বদলালে: weekly.channel = WhatsApp()

এই refactoring-এর পেছনের নীতিটি পুরোনো ও বিখ্যাত। ১৯৯৪ সালের Design Patterns বইয়ে (যার চার লেখককে “Gang of Four” বলা হয়) একটি বাক্য আছে: “Favor object composition over class inheritance” — class inheritance-এর চেয়ে object composition-কে প্রাধান্য দিন (ভাবনার প্রশ্ন ১)। লক্ষ করুন, বাক্যটি বলে “প্রাধান্য দিন”, “কখনো ব্যবহার করবেন না” নয়।

সিদ্ধান্তের সারণি

শেষ সারিটি খেয়াল করুন — inheritance খারাপ নয়। পর্ব ২৪-এ class InsufficientBalance(WalletError): লিখেছিলেন (আর WalletError এসেছিল Exception থেকে); সেটি একদম সঠিক inheritance, কারণ আপনার exception সত্যিই একটি WalletError, আর except WalletError তাকে ধরবে। সমস্যা inheritance-এ নয়, কোড বাঁচানোর জন্য inheritance-এ, আর গভীর গাছে। একটি ব্যবহারিক নিয়ম: inheritance-এর গভীরতা দুই-তিন তলার বেশি হলে থেমে ভাবুন।

৯ · AI-এর যুগে — অপ্রয়োজনীয় class-গাছ আর ভুলে যাওয়া super() ধরা

AI-কে “একটি ব্যাংক সিস্টেম লিখে দাও” বললে প্রায়ই সে একটি সুন্দর দেখতে class-গাছ বানায় — BaseEntity → BaseAccount → AbstractAccount → SavingsAccount. দেখতে “পেশাদার”, কিন্তু অনেক তলা কোনো আসল কাজ করে না। AI-এর প্রশিক্ষণের কোডে Java-ধাঁচের গভীর গাছ প্রচুর আছে, তাই সে সেটিই নকল করে, Python-এর duck typing আর composition-এর সুবিধা না নিয়ে। সাধারণ ভুলগুলো:

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

• প্রতিটি class X(Y)-এর জন্য জোরে বলেছি “X একটি Y” — বাক্যটি সব পরিস্থিতিতে সত্য কি না ভেবেছি (LSP)
• প্রতিটি subclass-এর __init__-এ super().__init__(...) আছে কি না দেখেছি
• isinstance খুঁজেছি (Ctrl+F); ব্যবসার যুক্তির ভেতরে if/elif-শৃঙ্খল থাকলে polymorphism চেয়েছি
• Multiple inheritance বা mixin থাকলে print(Class.__mro__) চালিয়ে ক্রমটি বুঝেছি
• dict, list বা str থেকে inherit করা class-এ override করা method আছে কি না দেখেছি; থাকলে update()/constructor দিয়ে পরীক্ষা করেছি
• কোনো base class বা তলা মুছে দিলে কী ভাঙে ভেবেছি — কিছু না ভাঙলে সেই তলাটি অপ্রয়োজনীয়