inheritance — উত্তরাধিকার, is-a সম্পর্ক

১ · Inheritance আসলে কী বলে — “এটি এক ধরনের …”

পর্ব ২-এ আপনি সমস্যাকে বস্তু আর তাদের দায়িত্বে ভাঙতে শিখেছেন, আর পর্ব ২০ থেকে ২৩-এ নিজের টাইপ বানাতে শিখেছেন — class, constructor, copy আর operator. এবার প্রশ্ন আসে টাইপদের মধ্যে সম্পর্ক নিয়ে। বাস্তব জগতে অনেক জিনিস অন্য জিনিসের বিশেষ রূপ। সঞ্চয়ী হিসাব এক ধরনের ব্যাংক হিসাব। ম্যানেজার এক ধরনের কর্মচারী। বৃত্ত এক ধরনের আকৃতি। এই “এক ধরনের” সম্পর্ককে ইংরেজিতে বলে is-a relationship, আর C++-এ সেটি লেখার উপায় হলো inheritance (উত্তরাধিকার)।

শেষ বাক্যটি গুরুত্বপূর্ণ। নতুনরা প্রায়ই inheritance-কে ভাবেন “কোড কপি না করে ধার নেওয়ার যন্ত্র”। একটি class-এ দরকারি কয়েকটি ফাংশন আছে, তাই সেখান থেকে inherit করে নিলাম — এই ভাবনা থেকেই খারাপ নকশার জন্ম। কোড পুনর্ব্যবহার inheritance-এর একটি ফল, উদ্দেশ্য নয়। আসল উদ্দেশ্য একটি প্রতিশ্রুতি: derived টাইপের object-কে base টাইপের জায়গায় নিশ্চিন্তে বসানো যাবে। কোড ধার নিতে চাইলে বেশিরভাগ সময় ভালো উপায় composition — অর্থাৎ অন্য object-কে নিজের সদস্য হিসেবে রাখা (“has-a”, যেমন গাড়ির একটি ইঞ্জিন আছে)। এই তুলনা পর্ব ২৭-এ গভীরে দেখবেন।

এই পর্বে তিনটি বাস্তব উদাহরণ বারবার আসবে: একটি অফিসের Employee আর তার বিশেষ রূপ Manager ও Intern (বেতনের নিয়ম আলাদা); একটি ব্যাংকের Account আর SavingsAccount (সুদ সহ); আর জ্যামিতির Shape. আগের class-টিকে বলে base class (মূল বা পিতৃ class), আর তার থেকে তৈরি নতুনটিকে derived class (উদ্ভূত class). কয়েক স্তরের এই সম্পর্ক মিলে তৈরি হয় একটি class hierarchy.

২ · Base আর derived class — syntax আর কী উত্তরাধিকারে আসে

প্রথমে একটি সাধারণ কর্মচারী। পর্ব ২০-এর নিয়ম মেনে data private, আর বাইরের দুনিয়ার জন্য কয়েকটি public ফাংশন:

class Employee {
public:
    Employee(std::string name, int baseSalary)
        : name_(std::move(name)), base_(baseSalary) {}
    const std::string& name() const { return name_; }
    int baseSalary() const { return base_; }
private:
    std::string name_;
    int base_;          // টাকায় মাসিক মূল বেতন
};

class Manager : public Employee {             // Manager এক ধরনের Employee
public:
    Manager(std::string name, int base, int teamSize)
        : Employee(std::move(name), base), teamSize_(teamSize) {}
    int teamAllowance() const { return teamSize_ * 1000; }  // শুধু Manager-এর
private:
    int teamSize_;
};

class Manager : public Employee — কোলনের পরে public শব্দটি বলে এটি public inheritance: Employee-এর public অংশ Manager-এরও public অংশ। এখন একটি Manager object-এর ওপর name(), baseSalary() আর teamAllowance() — তিনটিই ডাকা যায়। Employee-এর কোড Manager-এ একটি লাইনও কপি করতে হয়নি।

কী উত্তরাধিকারে আসে, কী আসে না

প্রথম সারিটা নতুনদের অবাক করে: private সদস্য derived object-এর ভেতরে আছে, অথচ derived ছুঁতে পারে না? হ্যাঁ — এবং এটাই ভালো। Employee-এর invariant (ধরুন, বেতন কখনো ঋণাত্মক নয়) রক্ষা করার দায়িত্ব Employee-এর। Manager যদি সরাসরি base_ = -500 লিখতে পারত, তাহলে সেই নিয়ম ভাঙার আরেকটি দরজা খুলে যেত। encapsulation শুধু বাইরের দুনিয়ার জন্য নয়, derived class-এর জন্যও।

এবার ভেতরের ছবিটা দেখুন। মেমরিতে একটি derived object আসলে কেমন দেখায়, আর একটি base reference তার কতটুকু দেখে — ধাপে ধাপে। (ঠিকানা আর ক্রম বোঝানোর জন্য সরল করা; বাস্তবে compiler padding যোগ করতে পারে।)

a :  ┌──────────────────────────────┐
     │ owner   = "Rina"             │
     │ balance = 5000               │
     └──────────────────────────────┘

s :  ┌──────────────────────────────┐
     │ Account অংশ (base subobject) │
     │   owner   = "Sakib"          │
     │   balance = 8000             │
     ├──────────────────────────────┤
     │ SavingsAccount-এর নিজের অংশ  │
     │   rate    = 4.5              │
     └──────────────────────────────┘

s :  ┌──────────────────────────────┐
r ──▶│ Account অংশ                  │  ◀ r এই অংশটিকে দেখে
     │   owner   = "Sakib"          │
     │   balance = 8000             │
     ├──────────────────────────────┤
     │ rate    = 4.5                │  ◀ আছে, কিন্তু r-এর চোখে অদৃশ্য
     └──────────────────────────────┘

r.deposit(500)   ✔  balance = 8500  (s-এর ভেতরেই বদলাল)
r.rate           ✘  error: 'class Account' has no member named 'rate'

r কোনো কপি নয় — s-এর base অংশের আরেকটি নাম।
তাই যে ফাংশন Account& নেয়, সে যেকোনো SavingsAccount-ও নিতে পারে।

৩ · protected — পরিবারের জন্য খোলা দরজা, সাবধানে

পর্ব ২০-এ আপনি দুটি access specifier দেখেছেন: public (সবার জন্য) আর private (শুধু class নিজে)। inheritance তৃতীয়টি নিয়ে আসে — protected: class নিজে আর তার derived class-রা ছুঁতে পারে, বাইরের কেউ পারে না।

শুনতে সুবিধাজনক — derived class-কে base-এর data সরাসরি ছুঁতে দিলে ঝামেলা কম। কিন্তু একটু থেমে ভাবুন। Account-এর balance যদি protected হয়, তাহলে এই প্রকল্পে ভবিষ্যতে যে কেউ যত derived class লিখবেন — StudentAccount, LoanAccount, কারও তাড়াহুড়োর TestAccount — প্রত্যেকেই balance সরাসরি বদলাতে পারবেন। “ব্যালান্স কখনো ঋণাত্মক নয়” নিয়মটি তখন আর এক জায়গায় রক্ষিত থাকে না; থাকে প্রতিটি derived class-এর সততার ওপর। protected data কার্যত সব derived class-এর জন্য public data, আর derived class-এর সংখ্যা আপনি নিয়ন্ত্রণ করতে পারেন না।

class Account {
public:
    void deposit(int taka) { if (taka > 0) balance_ += taka; }
    int balance() const { return balance_; }
protected:
    void addInterest(int taka) { balance_ += taka; }  // derived-দের জন্য নিয়ন্ত্রিত পথ
private:
    int balance_ = 0;                                  // data private-ই থাকল
};

class SavingsAccount : public Account {
public:
    void yearEnd() { addInterest(balance() * rate_ / 100); }  // ঠিক আছে
    // balance_ = -100;   // error: private — Account-এর নিয়ম রক্ষা পেল
private:
    int rate_ = 4;
};

লক্ষ্য করুন নকশাটি: data private, আর derived-দের যে বিশেষ সুবিধা দরকার, সেটি একটি protected ফাংশন হিসেবে। Account এখনো নিজের নিয়ম নিজে রক্ষা করছে; শুধু একটি নির্দিষ্ট, নামওয়ালা দরজা খোলা রেখেছে। এটাই ভালো রীতি।

৪ · তৈরি আর ধ্বংসের ক্রম — ভিত আগে, ছাদ পরে

একটি বহুতল ভবন বানাতে আগে ভিত, তারপর নিচতলা, তারপর ওপরের তলা। ভাঙার সময় উল্টো — আগে ছাদ, ভিত সবার শেষে। derived object-ও ঠিক এভাবে তৈরি হয়। কারণটা যুক্তিসংগত: derived-এর constructor চলার সময় সে base-এর ফাংশন ডাকতে পারে, তাই base অংশ তখন সম্পূর্ণ তৈরি থাকতেই হবে। আর ধ্বংসের সময় derived-এর destructor base-এর জিনিস ব্যবহার করতে পারে, তাই base অংশ তখনো বেঁচে থাকতে হবে।

base-এর constructor কীভাবে আর কোন যুক্তি দিয়ে ডাকা হবে, তা ঠিক করা হয় derived-এর constructor-এর member initializer list-এ — কোলনের পরের অংশে, যেমন : Account(std::move(o)), rate(r). সেখানে না লিখলে compiler base-এর default constructor ডাকার চেষ্টা করে; base-এর default constructor না থাকলে compile error. তিন স্তরের একটি hierarchy চালিয়ে দেখুন — Account থেকে SavingsAccount, তার থেকে ছাত্রদের জন্য বিশেষ StudentSavings:

#include <print>
#include <string>
#include <utility>

struct Account {
    std::string owner;
    explicit Account(std::string o) : owner(std::move(o)) { std::println("Account  ctor: {}", owner); }
    ~Account() { std::println("Account  dtor: {}", owner); }
};
struct Savings : Account {
    double rate;
    Savings(std::string o, double r) : Account(std::move(o)), rate(r) { std::println("Savings  ctor: rate {}%", rate); }
    ~Savings() { std::println("Savings  dtor"); }
};
struct StudentSavings : Savings {
    explicit StudentSavings(std::string o) : Savings(std::move(o), 5.5) { std::println("Student  ctor"); }
    ~StudentSavings() { std::println("Student  dtor"); }
};
int main() {
    StudentSavings s("Rina");
    std::println("--- using {} ---", s.owner);
}

একটা প্রশ্ন জাগে: StudentSavings-এর constructor-ই তো প্রথমে ডাকা হয়েছে, তাহলে তার লাইন শেষে কেন? কারণ constructor ডাকা আর তার body চলা এক জিনিস নয়। ডাকার পর আগে initializer list চলে, আর সেটি ওপরের স্তরের constructor ডাকে — body চলে সবার শেষে। ধাপে ধাপে দেখুন:

1StudentSavings s("Rina");                  // main2  StudentSavings(o) : Savings(o, 5.5)      // init list আগে3    Savings(o, r) : Account(o), rate(r)    // আবার init list4      Account(o) : owner(o) { println }    // সবার ওপরের স্তর5    Savings body   { println }6  StudentSavings body { println }7std::println("--- using ...");8}  // main শেষ: ~StudentSavings()9     → তারপর ~Savings()10     → সবশেষে ~Account()

একই constructor বারবার লিখবেন না — using Base::Base

কখনো derived class নতুন কোনো data যোগ করে না, শুধু নতুন আচরণ যোগ করে। তখনো base-এর প্রতিটি constructor-এর জন্য একটি করে “যুক্তি নিয়ে base-কে দিয়ে দাও” constructor লেখা বিরক্তিকর। C++11 থেকে একটি লাইনেই সব নিয়ে আসা যায় — একে বলে inheriting constructors:

class Intern : public Employee {
public:
    using Employee::Employee;            // Employee(name, baseSalary) এখন Intern-এরও
    int stipend() const { return std::min(baseSalary(), 15000); }  // ভাতার সর্বোচ্চ সীমা
};

Intern i{"Nusrat", 12000};               // উত্তরাধিকারে পাওয়া constructor

সাবধান: derived class যদি নিজের নতুন data member যোগ করে, inheriting constructor সেটিকে initialize করবে না — শুধু default member initializer (যেমন int level_ = 1;) থাকলে সেটি কাজে লাগবে। নতুন data-র জন্য সঠিক মান দরকার হলে নিজের constructor লিখুন।

৫ · Name hiding — একই নামের ফাংশন base-এর সবকিছু ঢেকে দেয়

এখন একটি ফাঁদ, যা অভিজ্ঞ প্রোগ্রামারদেরও অবাক করে। ধরুন Employee-এর দুটি pay ফাংশন আছে (পর্ব ৯-এর overloading): একটি শুধু টাকার অঙ্ক নেয়, আরেকটি সাথে একটি নোট। Intern-এর জন্য নিয়ম আলাদা — ভাতার সীমা আছে — তাই Intern নিজের pay(int) লিখল:

class Employee {
public:
    void pay(int taka);
    void pay(int taka, const std::string& note);
};
class Intern : public Employee {
public:
    void pay(int taka);                  // সীমা যাচাই করে টাকা দেয়
};

Intern n;
n.pay(8000);                             // ঠিক আছে — Intern::pay(int)
n.pay(8000, "July stipend");             // error! কেন?

দ্বিতীয় লাইনটি compile হয় না, যদিও Employee-এ ঠিক এমন একটি ফাংশন আছে। কারণ C++-এর name lookup নাম খোঁজে আগে, overload বাছাই করে পরে। ধাপে ধাপে দেখুন compiler কী ভাবে:

খোঁজ শুরু n-এর টাইপ থেকে →  Intern
                                │
                                ▼  (পাওয়া না গেলে ওপরে যাবে)
                             Employee

Intern     : pay(int)                 ◀ "pay" পাওয়া গেল, এখানেই থামো
Employee   : pay(int)
             pay(int, const std::string&)   ◀ দেখাই হলো না

প্রার্থী:  Intern::pay(int)
যুক্তি  :  (int, const char*)      → ২টি যুক্তি, ফাংশন নেয় ১টি

error: no matching function for call to 'Intern::pay(int, const char [13])'
note: candidate: 'void Intern::pay(int)'

Intern     : pay(int)                         ◀ Intern-এর নিজের (এটিই জেতে)
             pay(int, const std::string&)  ◀ using দিয়ে আনা

n.pay(8000)                   → Intern::pay(int)
n.pay(8000, "July stipend")   → Employee::pay(int, const std::string&)  ✔

নিয়মটি কেন এমন? ভাবুন, Employee লেখা হয়েছে অন্য দলে, আর পরে কেউ সেখানে নতুন একটি pay(double) যোগ করলেন। name hiding না থাকলে Intern-এর পুরোনো কোড n.pay(8000) হঠাৎ নতুন কোনো overload-এ চলে যেতে পারত, কেউ টের না পেয়ে। C++ তাই নিরাপদ পথ নিয়েছে: derived class নামটি নিজে ঘোষণা করলে সেই নামের পুরো দায়িত্ব তার। base-এর overload চাইলে স্পষ্ট করে using লিখে আনতে হবে।

৬ · Object slicing — কপি করলে derived অংশ কেটে যায়

অংশ ২-এর মেমরির ছবি মনে করুন: SavingsAccount-এর ভেতরে একটি Account অংশ, তার নিচে rate. এখন যদি একটি SavingsAccount-কে একটি Account ভ্যারিয়েবলে কপি করেন, কী হবে? Account ভ্যারিয়েবলে জায়গা আছে শুধু owner আর balance-এর জন্য। rate রাখার জায়গাই নেই। তাই কপি হয় শুধু base অংশ — বাকিটা কেটে বাদ পড়ে, যেভাবে পাউরুটির এক টুকরো কেটে নেওয়া হয়। একে বলে object slicing.

এখানে সমস্যা শুধু একটি সংখ্যা হারানো নয়। হারায় object-এর পরিচয়। দেখতে নিচের উদাহরণে আমরা পর্ব ২৫-এর একটি জিনিস আগেভাগে ব্যবহার করছি — virtual function: virtual লেখা ফাংশন ডাকলে object-এর আসল টাইপের সংস্করণ চলে। এর পুরো ব্যাখ্যা পরের পর্বে; আজ শুধু দেখুন slicing সেই আসল টাইপকে কীভাবে মুছে দেয়:

#include <print>
#include <string>
#include <vector>

struct Account {
    double balance = 0;
    virtual std::string kind() const { return "Account"; }   // virtual: see part 25
    virtual ~Account() = default;
};
struct Savings : Account {
    double rate = 4.0;
    std::string kind() const override { return "Savings"; }
};
void byValue(Account a)      { std::println("by value    : {}", a.kind()); }
void byRef(const Account& a) { std::println("by reference: {}", a.kind()); }
int main() {
    Savings s;
    byValue(s);  byRef(s);
    std::vector<Account> v{s};                  // copied into an Account slot
    std::println("in vector   : {}", v[0].kind());
    std::println("sizes       : {} vs {}", sizeof(Account), sizeof(Savings));
}

s :  ┌───────────────────────────┐
     │ [টাইপ-চিহ্ন → Savings]     │
     │ balance = 0               │  ◀ Account অংশ
     ├───────────────────────────┤
     │ rate    = 4.0             │  ◀ Savings অংশ
     └───────────────────────────┘

s :  ┌───────────────────────────┐        a :  ┌───────────────────────────┐
     │ [→ Savings]               │             │ [টাইপ-চিহ্ন → Account]    │
     │ balance = 0               │ ──কপি──▶    │ balance = 0               │
     ├───────────────────────────┤             └───────────────────────────┘
     │ rate    = 4.0             │ ──✂──  কোথাও যায় না
     └───────────────────────────┘

a.kind()  →  "Account"

a-কে Account-এর copy constructor বানিয়েছে, তাই a জন্ম থেকেই Account.
এটা bug নয় — ভাষা যা বলেছে, তা-ই করেছে। ভুল আমাদের: by value চেয়েছি।

s :  ┌───────────────────────────┐
a ──▶│ [→ Savings]               │
     │ balance = 0               │
     ├───────────────────────────┤
     │ rate    = 4.0             │   ◀ অক্ষত
     └───────────────────────────┘
a.kind()  →  "Savings"

v :  [ Account | Account | Account | ... ]   প্রতি ঘর sizeof(Account)
           ▲
           └── s-এর শুধু Account অংশ, rate কেটে গেছে

সমাধান: std::vector<std::unique_ptr<Account>> v;
         v.push_back(std::make_unique<Savings>());   // object আস্ত থাকে heap-এ

৭ · public, protected আর private inheritance

এ পর্যন্ত সব উদাহরণে কোলনের পরে public লিখেছি। আরও দুটি বিকল্প আছে। এগুলো ঠিক করে, base-এর public আর protected সদস্যরা derived-এ এসে কী হবে — আর তার চেয়েও গুরুত্বপূর্ণ, বাইরের দুনিয়া কি জানবে যে “derived এক ধরনের base”?

base-এর private সদস্য তিন ক্ষেত্রেই derived-এর কাছে অপ্রবেশ্য থাকে — inheritance-এর ধরন শুধু public আর protected সদস্যদের ভাগ্য বদলায়।

private inheritance-এর অর্থ is-a নয়। এর অর্থ “আমি ভেতরে ভেতরে ওই class দিয়ে বানানো, কিন্তু বাইরে কাউকে বলব না”। বাইরের কোড Derived-কে Base হিসেবে ব্যবহার করতে পারে না। একই কাজ প্রায় সবসময় composition দিয়ে আরও পরিষ্কারভাবে হয় — Base-কে একটি private সদস্য করে রাখা। private inheritance-এর বৈধ ব্যবহার অল্প কিছু, যেমন base-এর কোনো virtual ফাংশন নতুন করে লিখতে হলে, বা খালি class-এর জায়গা বাঁচানোর পুরোনো কৌশলে (C++20 থেকে এর জন্য [[no_unique_address]] সদস্যও আছে)। protected inheritance বাস্তব কোডে আরও বিরল।

৮ · Multiple inheritance, diamond আর final

C++-এ একটি class একাধিক base থেকে inherit করতে পারে — একে বলে multiple inheritance. যেমন একটি স্মার্টফোন এক ধরনের ক্যামেরা, আবার এক ধরনের ফোনও: class SmartPhone : public Camera, public Phone. বাস্তবে সবচেয়ে নিরাপদ আর প্রচলিত ব্যবহার হলো একটি আসল base আর কয়েকটি ছোট “interface” (যাদের data নেই, শুধু ফাংশনের প্রতিশ্রুতি — পর্ব ২৬-এ)। দুটি base-এ একই নামের সদস্য থাকলে phone.Camera::powerOn() লিখে স্পষ্ট করতে হয়, নইলে compiler “ambiguous” বলে থামে।

Diamond সমস্যা

ঝামেলা বাধে যখন দুটি base নিজেরাই একই base থেকে আসে। ধরুন একটি বিশ্ববিদ্যালয়ের সিস্টেমে Person থেকে Student আর Staff, আর একজন টিচিং অ্যাসিস্ট্যান্ট দুটিই — TA : Student, Staff. ছবিটা হীরার (diamond) মতো:

//          Person
//         /      \    (দুই দিকে)
//    Student    Staff
//         \      /
//            TA
struct Person  { std::string name; };
struct Student : Person { int roll; };
struct Staff   : Person { int salary; };
struct TA : Student, Staff { };

TA t;
t.name = "Mim";       // error: request for member 'name' is ambiguous
                      // TA-র ভেতরে দুটি Person অংশ — কোনটির name?

সাধারণ inheritance-এ প্রতিটি base অংশ আলাদা, তাই TA-র ভেতরে দুটি আলাদা Person — দুটি নাম, যা একসময় আলাদা হয়ে যেতে পারে। এটাই diamond problem. C++-এর উত্তর virtual inheritance: struct Student : virtual Person আর struct Staff : virtual Person লিখলে TA-র ভেতরে Person অংশ থাকে একটিই, দুজনে ভাগ করে নেয়। standard library-তেও এর উদাহরণ আছে: std::iostream আসে std::istream আর std::ostream দুটি থেকে, আর তারা দুজনেই virtual-ভাবে একই base (std::basic_ios) থেকে।

তবে virtual inheritance-এর দাম আছে। শেয়ার করা base অংশটির constructor ডাকার দায়িত্ব চলে যায় সবচেয়ে নিচের class-এর (এখানে TA) কাছে, মাঝের Student বা Staff-এর initializer list তখন সেই ডাক উপেক্ষা হয়। object-এর বিন্যাস জটিল হয়, base অংশে পৌঁছাতে বাড়তি ধাপ লাগে। তাই নতুন নকশায় diamond দেখলে আগে প্রশ্ন করুন, নকশাটাই ঠিক কি না। প্রায়ই উত্তর হয়: TA একজন Person, যার একটি Student-ভূমিকা আর একটি Staff-ভূমিকা আছে — composition.

final — এখানেই শেষ

কিছু class-কে আর derive করা উচিত নয় — হয়তো তার invariant এত সূক্ষ্ম যে কেউ বাড়িয়ে লিখলে ভাঙবে, বা আপনি চান ভবিষ্যতে ভেতরের নকশা স্বাধীনভাবে বদলাতে। C++11 থেকে final দিয়ে সেটা বলা যায়:

class Money final { /* ... */ };
class MyMoney : public Money { };   // error: cannot derive from 'final' base 'Money'

final virtual ফাংশনের ওপরও বসে (“এর পরে কেউ এই ফাংশন বদলাতে পারবে না”) — সেটি পর্ব ২৫-এ। একটি ভালো অভ্যাস: যে class-কে আপনি base হিসেবে ব্যবহারের জন্য নকশা করেননি, তাকে খোলা রাখার বদলে final ভাবুন।

৯ · Liskov নীতি — বর্গ কি সত্যিই এক ধরনের আয়ত?

is-a কথাটা মুখে বলা সহজ। কিন্তু কীভাবে যাচাই করবেন, সম্পর্কটা সত্যিই is-a কি না? এর পরিষ্কার উত্তর দিয়েছেন কম্পিউটার বিজ্ঞানী Barbara Liskov. সহজ ভাষায় তাঁর নীতি — Liskov Substitution Principle (LSP): যে কোড base টাইপের object নিয়ে ঠিকঠাক চলে, তাকে একটি derived object দিলেও সে ঠিকঠাক চলবে — কোনো চমক ছাড়া। derived class base-এর প্রতিশ্রুতি রাখবে, ভাঙবে না।

বিখ্যাত উদাহরণটি দেখুন। গণিতে প্রতিটি বর্গ একটি আয়ত — চার কোণ সমকোণ, শুধু বাহু চারটি সমান। তাহলে কোডে Square : public Rectangle তো স্বাভাবিক, তাই না?

class Rectangle {
public:
    virtual void setWidth(int w)  { w_ = w; }
    virtual void setHeight(int h) { h_ = h; }
    int area() const { return w_ * h_; }
private:
    int w_ = 0, h_ = 0;
};
class Square : public Rectangle {          // “বর্গ এক ধরনের আয়ত”?
public:
    void setWidth(int w)  override { Rectangle::setWidth(w); Rectangle::setHeight(w); }
    void setHeight(int h) override { Rectangle::setWidth(h); Rectangle::setHeight(h); }
};

void resize(Rectangle& r) {                // Rectangle-এর জন্য লেখা, যুক্তিসংগত কোড
    r.setWidth(5);
    r.setHeight(4);
    assert(r.area() == 20);                // Square দিলে area 16 — ভেঙে গেল!
}

resize-এর লেখক একটি যুক্তিসংগত ধারণা করেছেন: আয়তের প্রস্থ আর উচ্চতা আলাদাভাবে বদলানো যায়। Rectangle-এর প্রতিশ্রুতি এটাই। Square সেই প্রতিশ্রুতি রাখতে পারে না — উচ্চতা বদলালে প্রস্থও বদলে যায়। ফলে Square-কে Rectangle-এর জায়গায় বসালে কোড ভাঙে। গণিতের “is-a” আর কোডের “is-a” এক নয়। কোডে is-a মানে আচরণে বদলে ব্যবহারযোগ্য।

সমাধান কী? কয়েকটি পথ আছে, পরিস্থিতি বুঝে: (ক) আকারগুলোকে বদলানোর অযোগ্য (immutable) রাখুন — নতুন মাপ চাইলে নতুন object. তখন “প্রস্থ আলাদা বদলানো” প্রতিশ্রুতিটাই থাকে না, আর Square-কে Rectangle-এর মতো ব্যবহার করা নিরাপদ। (খ) Square আর Rectangle দুজনকেই একটি সাধারণ Shape-এর সন্তান করুন, যার প্রতিশ্রুতি শুধু “আমার একটি ক্ষেত্রফল আছে” — কেউ কারও সন্তান নয়। (গ) আদৌ hierarchy না রেখে আলাদা টাইপ রাখুন।

১০ · AI-এর যুগে — AI-এর বানানো class hierarchy যাচাই

“একটি HR সিস্টেম লেখো” বললে AI টুল প্রায়ই চমৎকার দেখতে একটি class hierarchy দেয় — BaseEntity থেকে Person, তার থেকে Employee, তার থেকে FullTimeEmployee, তার থেকে SeniorManager… কারণ প্রশিক্ষণের অনেক পুরোনো Java-ধাঁচের কোডে এমন গভীর গাছ আছে। কোড compile হয়, চলেও। সমস্যা ধরা পড়ে পরে — নতুন একটি নিয়ম যোগ করতে গিয়ে, বা যখন দেখা যায় বেতনের হিসাব কিছু কর্মচারীর জন্য ভুল আসছে। AI-এর সাধারণ ভুলগুলো:

AI-এর লেখা hierarchy যাচাইয়ের চেকলিস্ট

• প্রতিটি : public Base-এর জন্য বাক্যটি বলেছি — “প্রতিটি D এক ধরনের B” — আর Liskov প্রশ্ন করেছি: B& নেয় এমন কোডে D দিলে কোনো চমক আছে কি?
• hierarchy-র গভীরতা গুনেছি; তিন স্তরের বেশি হলে কারণ জিজ্ঞেস করেছি, আর কোথায় composition চলত, ভেবেছি
• protected শব্দটি খুঁজেছি — data-র পাশে পেলে private করে protected ফাংশন দিতে বলেছি
• by value base প্যারামিটার, std::vector<Base> আর for (auto x : ...) খুঁজেছি — slicing-এর তিনটি সাধারণ উৎস
• derived-এ base-এর কোনো ফাংশনের নাম আবার ব্যবহার হলে দেখেছি base-এ তার overload আছে কি না (name hiding)
• constructor-destructor-এ প্রিন্ট বসিয়ে চালিয়েছি: তৈরি base থেকে নিচে, ধ্বংস নিচ থেকে base-এ — প্রতিটি ঠিক একবার