polymorphism ও virtual ফাংশন — একই ডাক, ভিন্ন কাজ

১ · সমস্যাটা আগে — একটি checkout, অনেক রকম পেমেন্ট

ধরুন আপনি একটি অনলাইন দোকানের checkout অংশ লিখছেন। ক্রেতা দাম দিতে পারেন bKash, Nagad বা ব্যাংকের কার্ড দিয়ে। প্রতিটি পদ্ধতির নিজের নিয়ম আছে — কারও চার্জ শতাংশে, কারও একটি নির্দিষ্ট টাকা যোগ করে, কারও যাচাইয়ের ধাপ আলাদা। আগের পর্বে আপনি inheritance দেখেছেন: একটি base class Payment, আর তা থেকে তৈরি derived class Bkash, Nagad, Card. কিন্তু শুধু উত্তরাধিকার দিয়ে আসল প্রশ্নের উত্তর মেলে না: checkout-এর কোড কীভাবে জানবে, এই মুহূর্তের ক্রেতা কোন পদ্ধতি বেছে নিয়েছেন?

প্রথম যে সমাধান মাথায় আসে, তা হলো টাইপ জিজ্ঞেস করে করে কাজ করা:

// পুরোনো পথ: টাইপ দেখে দেখে সিদ্ধান্ত (type switch)
int fee(const Payment& p, int taka) {
    switch (p.kind) {                    // প্রতিটি object-এ একটি "kind" লেবেল
        case Kind::Bkash: return taka * 18 / 1000;
        case Kind::Nagad: return taka * 15 / 1000;
        case Kind::Card:  return 20 + taka / 100;
    }
    return 0;
}
// ...আর একই switch আবার refund()-এ, receipt()-এ, verify()-এ...

কোডটি চলে। সমস্যা দেখা দেয় ছয় মাস পরে, যখন ব্যবসায় Rocket বা নতুন কোনো ওয়ালেট যোগ করতে হয়। তখন খুঁজে খুঁজে বের করতে হয়, প্রোগ্রামের কোথায় কোথায় এমন switch আছে — fee-তে, refund-এ, রসিদ ছাপায়, যাচাইয়ে। একটি জায়গা বাদ পড়লে নতুন ওয়ালেটের ক্রেতা হয় শূন্য চার্জ দেবেন, নয়তো ভুল রসিদ পাবেন। আর কেউ টের পাবে না, কারণ compiler এখানে কোনো ভুল দেখে না। নতুন টাইপ যোগ করা মানে পুরোনো, পরীক্ষিত কোড খুলে বদলানো — ঠিক যেটা বড় সফটওয়্যারে সবচেয়ে ঝুঁকির কাজ।

Polymorphism শব্দটি গ্রিক — poly মানে “অনেক”, morph মানে “রূপ”। প্রোগ্রামিংয়ে এর মানে: একই নামের একটি ডাক, কিন্তু কোন কোডটি চলবে তা নির্ভর করে কার ওপর ডাকা হলো তার ওপর। C++-এ polymorphism কয়েক রকম আছে — পর্ব ৯-এর function overloading-ও এক অর্থে polymorphism, পর্ব ২৮-এর template-ও। আজকের বিষয় সবচেয়ে পরিচিত রূপটি: চলার সময়ের (run-time) polymorphism, যার যন্ত্র হলো virtual ফাংশন।

২ · Static binding বনাম dynamic binding — কে, কখন সিদ্ধান্ত নেয়

একটি ফাংশন-ডাক লিখলে কাউকে না কাউকে ঠিক করতে হয়, ঠিক কোন ফাংশনের কোড চলবে। এই সংযোগ করাকে বলে binding. C++-এ এটি দুটি সময়ে হতে পারে।

প্রথমে দুটি শব্দ পরিষ্কার করে নিন। const Payment& p = bk; লিখলে p-এর static type হলো Payment& — যা কোডে লেখা আছে, compiler যা দেখে। কিন্তু p আসলে যে object-কে দেখাচ্ছে, সেটি একটি Bkash — এটি dynamic type, যা শুধু চলার সময় নিশ্চিতভাবে জানা যায়। derived object-কে base reference বা pointer দিয়ে ধরাকে বলে upcast, আর C++ এটি নিজে থেকেই, কোনো cast ছাড়াই করতে দেয় — কারণ প্রতিটি Bkash একটি Payment (“is-a” সম্পর্ক, পর্ব ২৪)।

Static binding হলো ট্রেনের নির্দিষ্ট টিকিটের মতো — টিকিট কাটার সময়েই সিট নম্বর লেখা, স্টেশনে গিয়ে আর কিছু ভাবতে হয় না। Dynamic binding হলো রাইড-শেয়ারিং অ্যাপে গাড়ি ডাকার মতো — আপনি শুধু বলেন “একটি গাড়ি চাই”, কোন চালক আসবেন, তা ঠিক হয় ডাকার মুহূর্তে।

একটি জিনিস খেয়াল করুন: overloading (পর্ব ৯) আর template-ও এক রকম polymorphism, কিন্তু দুটিতেই সিদ্ধান্ত হয় compile-এর সময়। তাই এদের বলে compile-time polymorphism. আর virtual ফাংশন দেয় run-time polymorphism. দুটিরই জায়গা আছে — এই পর্বের শেষে আবার এ প্রসঙ্গে ফিরব।

৩ · virtual ফাংশন — base-এর মাধ্যমে ডাক, derived-এর কাজ

base class-এ কোনো member function-এর আগে virtual লিখলে আপনি compiler-কে বলছেন: “এই ফাংশনটি derived class বদলে দিতে পারে; reference বা pointer দিয়ে ডাকা হলে আসল object-এর সংস্করণটিই চালাবে।” এমন ফাংশনকে বলে virtual function. derived class-এ একই নাম, একই প্যারামিটার আর একই const-সহ ফাংশন লিখলে সেটি base-এর সংস্করণকে override করে।

এবার checkout-এর পুরো ধারণাটি একটি ছোট প্রোগ্রামে দেখুন। চার্জের হারগুলো শুধু উদাহরণ (আসল হার নয়), আর হিসাব পূর্ণসংখ্যায়, যাতে আউটপুট সব জায়গায় এক থাকে। চারটি ভিন্ন টাইপের object একটি তালিকায় রাখা আছে, আর লুপের একটিমাত্র লাইন সবার জন্য একই ডাক দেয়:

#include <memory>
#include <print>
#include <vector>

struct Payment {                                   // base class
    virtual ~Payment() = default;                  // virtual destructor
    virtual int fee(int) const { return 0; }       // default: cash, no fee
};
struct Bkash : Payment { int fee(int t) const override { return t * 18 / 1000; } };
struct Nagad : Payment { int fee(int t) const override { return t * 15 / 1000; } };
struct Card final : Payment { int fee(int t) const override { return 20 + t / 100; } };

int main() {
    std::vector<std::unique_ptr<Payment>> pay;     // many types, one list
    pay.push_back(std::make_unique<Payment>());
    pay.push_back(std::make_unique<Bkash>());
    pay.push_back(std::make_unique<Nagad>());
    pay.push_back(std::make_unique<Card>());
    for (const auto& p : pay) std::println("fee on 5000 = {}", p->fee(5000));
}

লুপের সেই একটি লাইন চারবার চলার সময় কোন ফাংশন কেন বেছে নেওয়া হলো, ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন:

1struct Payment { virtual int fee(int) const { return 0; } };2struct Bkash : Payment { ... return t * 18 / 1000; };3struct Nagad : Payment { ... return t * 15 / 1000; };4struct Card final : Payment { ... return 20 + t / 100; };5for (const auto& p : pay)6    std::println("fee on 5000 = {}", p->fee(5000));

কেন reference বা pointer লাগে — object slicing

dynamic binding কাজ করে শুধু reference বা pointer দিয়ে ডাকলে। base টাইপের একটি সাধারণ ভ্যারিয়েবলে derived object কপি করলে কী হয়, দেখুন:

Bkash bk;
Payment byValue = bk;          // কপি: শুধু Payment অংশটুকু কপি হলো
const Payment& byRef = bk;     // reference: আসল bk-কেই দেখছে

byValue.fee(5000);             // 0  — এটি এখন সত্যিই একটি Payment
byRef.fee(5000);               // 90 — Bkash::fee
// একই ভুল ফাংশনের প্যারামিটারে: void checkout(Payment p) — by value নেবেন না

Payment টাইপের একটি ভ্যারিয়েবলে শুধু Payment-এর মাপের জায়গা আছে। Bkash-কে সেখানে কপি করলে বাড়তি অংশ কেটে বাদ পড়ে, আর নতুন object-টি আগাগোড়া একটি Payment. একে বলে object slicing — যেন একটি পুরো মাছের শুধু লেজের দিকটা কেটে রাখলেন, আর ভাবলেন মাছটি এখনো আস্ত আছে। তাই polymorphic object ফাংশনে পাঠান const Payment& বা Payment& দিয়ে, আর একসাথে অনেকগুলো রাখুন pointer-এ — যেমন উপরের unique_ptr-এর vector.

৪ · override আর final — নীরব ভুলকে জোরালো error বানানো

virtual ফাংশনের সবচেয়ে বিপজ্জনক ভুলগুলো compile হয়, চলে, আর চুপচাপ ভুল ফল দেয়। সবচেয়ে সাধারণটি: base-এ virtual লিখতে ভুলে যাওয়া। তখন derived-এর একই নামের ফাংশনটি override করে না — শুধু base-এরটিকে আড়াল করে (hide). ফলে base reference দিয়ে ডাকলে base-এর ফাংশনই চলে। bKash-এর ক্রেতার কাছ থেকে চার্জ কাটা হলো না, আর কোনো error-ও এল না। ঘটনাটি ধাপে ধাপে দেখুন:

struct Payment { int fee(int) const { return 0; } };       // virtual নেই!
struct Bkash : Payment { int fee(int t) const { return t * 18 / 1000; } };

Bkash bk;
const Payment& p = bk;
std::println("{}", p.fee(5000));

p.fee(5000)
  p-এর ঘোষিত টাইপ: const Payment&
  Payment::fee কি virtual?  না
  => সিদ্ধান্ত এখনই: সরাসরি Payment::fee ডাকো
     (মেশিন কোডে: call Payment::fee — ঠিকানা স্থির)

আউটপুট:  0

p আসলে একটি Bkash-কে দেখাচ্ছে, কিন্তু তাতে কিছু যায় আসে না —
ডাকের ঠিকানা compile-এর সময়েই বাঁধা হয়ে গেছে।
কোনো error নেই, কোনো warning নেই। ক্রেতার চার্জ: 0 টাকা।

struct Payment { virtual int fee(int) const { return 0; } };
struct Bkash : Payment { int fee(int t) const override { return t * 18 / 1000; } };

আউটপুট:  90

আর base-এ virtual না থাকলে override-ই error দিত:
error: 'virtual int Bkash::fee(int) const' marked 'override', but does not override

override — “আমি বদলাতে চাইছি”, compiler যাচাই করুক

C++11 থেকে derived-এর ফাংশনের শেষে override লেখা যায়। এর মানে: “এই ফাংশন base-এর একটি virtual ফাংশনকে বদলাচ্ছে।” মিল না পেলে compile error. কোন কোন ভুল এটি ধরে:

struct Notifier {
    virtual void send(const std::string& msg) const;
};
struct Sms : Notifier {
    void send(const std::string& msg) override;        // error: const বাদ পড়েছে
    void sned(const std::string& msg) const override;  // error: বানান ভুল
    void send(std::string msg) const override;         // error: প্যারামিটারের টাইপ আলাদা
    void send(const std::string& msg) const override;  // ঠিক
};

override ছাড়া প্রথম তিনটি লাইন নীরবে নতুন, আলাদা ফাংশন তৈরি করত — আর base reference দিয়ে ডাকলে চলত base-এর send. বিশেষ করে const বাদ পড়া খুব সাধারণ, কারণ চোখে প্রায় একই দেখায়। আরেকটি সুবিধা: কেউ পরে base-এর ফাংশনের স্বাক্ষর বদলালে (ধরুন একটি প্যারামিটার যোগ করলেন), সব derived class-এ সঙ্গে সঙ্গে error আসবে — কোনো সংস্করণ পেছনে পড়ে থাকবে না। নিয়মটা তাই সরল: derived class-এ প্রতিটি override-এ override লিখুন; সেখানে আবার virtual লেখার দরকার নেই। (C++ Core Guidelines-ও ঠিক এটাই বলে। GCC-তে -Wsuggest-override দিলে override বাদ পড়া জায়গাগুলো দেখায়।)

final — “এখানেই শেষ”

final দুই জায়গায় বসে। class-এর নামের পরে (struct Card final : Payment) বসালে Card থেকে আর কোনো class তৈরি করা যাবে না। একটি virtual ফাংশনের পরে (int fee(int t) const final;) বসালে আরও নিচের কোনো class এই ফাংশন আর বদলাতে পারবে না। এটি নকশার একটি স্পষ্ট ঘোষণা — যেমন নিরাপত্তা-সংক্রান্ত যাচাইয়ের ফাংশন, যা কেউ ভুল করে বদলে দিক তা আপনি চান না। বাড়তি লাভ: compiler জানে এর নিচে আর কেউ নেই, তাই কিছু ক্ষেত্রে virtual ডাককে সরাসরি ডাকে বদলে দিতে পারে (৬ নম্বর অংশ দেখুন)। তবে সব class-এ অভ্যাসবশত final বসাবেন না; যেখানে সত্যিই আর বাড়ানোর কথা নয়, শুধু সেখানে।

৫ · Virtual destructor — যে নিয়ম ভাঙলে undefined behavior

polymorphic object প্রায়ই heap-এ থাকে আর base টাইপের pointer দিয়ে ধরা থাকে — ঠিক উপরের std::unique_ptr<Payment>-এর মতো। সেই pointer যখন object-টি মোছে, তখন কোন destructor চলবে? এখানেও একই binding-এর নিয়ম খাটে। destructor virtual না হলে compiler শুধু pointer-এর ঘোষিত টাইপ দেখে — ~Payment().

struct Payment {
    ~Payment() { }                        // virtual নয় — বিপদ
    virtual int fee(int) const { return 0; }
};
struct Card : Payment {
    std::vector<std::string> log;         // Card-এর নিজের heap রিসোর্স
    int fee(int t) const override { return 20 + t / 100; }
};

std::unique_ptr<Payment> p = std::make_unique<Card>();
// p ধ্বংস হলে: delete (Payment*) — Card অংশের destructor চলার নিশ্চয়তা নেই
// C++ standard-এর ভাষায়: undefined behavior. (এই কোড চালাবেন না)

derived object-কে এমন base pointer দিয়ে delete করা, যার destructor virtual নয় — C++ standard একে সরাসরি undefined behavior বলে। বাস্তবে সাধারণত যা ঘটে: শুধু Payment অংশের destructor চলে, Card-এর log vector-এর মেমরি আর কখনো ফেরত যায় না (leak); derived অংশে ফাইল বা lock থাকলে সেগুলোও আটকে থাকে। একাধিক base থাকলে ভুল ঠিকানা মুছে প্রোগ্রাম crash-ও করতে পারে। কিন্তু “সাধারণত” কথাটাই এখানে ফাঁদ — UB মানে compiler কোনো কিছুরই নিশ্চয়তা দেয় না।

সমাধান একটি লাইন, যা আমরা কোডে আগেই লিখেছি:

struct Payment {
    virtual ~Payment() = default;         // এখন delete আসল টাইপের destructor চালায়
    virtual int fee(int) const { return 0; }
};

৬ · ভেতরে কী ঘটে — vtable আর vptr

চলার সময় “আসল টাইপ দেখে ঠিক ফাংশন খুঁজে নেওয়া” কথাটি শুনতে জাদুর মতো লাগে। C++ standard শুধু আচরণটি বলে দেয়, কীভাবে করতে হবে তা বলে না। কিন্তু GCC, Clang, MSVC — বাস্তবের প্রায় সব compiler একই মূল কৌশল ব্যবহার করে। নিচের ছবিটি সেই সাধারণ কৌশল, সরল করে দেখানো। এটি implementation detail — প্রচলিত, কিন্তু standard-এর নিশ্চয়তা নয়।

• vtable (virtual table): virtual ফাংশন আছে এমন প্রতিটি class-এর জন্য compiler একটি তালিকা বানায় — সেই class-এর প্রতিটি virtual ফাংশনের ঠিকানা, নির্দিষ্ট ক্রমে। Bkash-এর তালিকার “fee”-এর ঘরে থাকে Bkash::fee-এর ঠিকানা, Nagad-এর তালিকায় Nagad::fee-এর। তালিকাটি class-প্রতি একটি, সব object ভাগ করে নেয়, আর থাকে প্রোগ্রামের শুধু-পড়ার অংশে।
• vptr (virtual pointer): প্রতিটি object-এর ভেতরে compiler একটি লুকানো pointer রাখে, যা নিজের class-এর vtable দেখায়। প্রচলিত ব্যবস্থায় এটি object-এর একেবারে শুরুতে থাকে। constructor-ই এটি ঠিক করে দেয় — object কোন টাইপ হিসেবে জন্মাল, সেই অনুযায়ী।

এবার p->fee(5000) লাইনটি চলার মুহূর্তে CPU আসলে কী করে, ধাপে ধাপে দেখুন। compiler আগেই জানে, fee হলো vtable-এর ১ নম্বর ঘর — কারণ ক্রমটি base class দেখেই ঠিক করা:

p  ──►  @5000  (ঠিকানাটি উদাহরণমাত্র)
compiler জানে: এখানে একটি Payment আছে — কিন্তু কোন ধরনের, জানে না।

@5000:  [ vptr = @V_Bkash ]   ← constructor এটি বসিয়েছিল
@5008:  [ Bkash-এর নিজের ডেটা ... ]

[0]  ~Bkash()
[1]  Bkash::fee     ← compiler আগেই জানত: fee = ঘর 1

ঠিকানা পাওয়া গেল: Bkash::fee-এর কোড যেখানে আছে
(Nagad object হলে এখানে পেত Nagad::fee — বাকি ধাপ হুবহু এক)

call [ঠিকানা]  with this = @5000, t = 5000
=> return 5000 * 18 / 1000  =  90

খরচ কত — আর কখন সেটা গুরুত্বপূর্ণ

virtual ফাংশনের দাম তিন রকম। এক, প্রতি ডাকে একটি বাড়তি পরোক্ষ ধাপ — আধুনিক CPU-তে সাধারণত কয়েক ন্যানোসেকেন্ডের কম, বিশেষ করে যখন CPU আগের অভিজ্ঞতা থেকে লাফের গন্তব্য ঠিক অনুমান করতে পারে। দুই, প্রতিটি object-এ একটি বাড়তি pointer — ৬৪-বিট সিস্টেমে সাধারণত ৮ বাইট। কোটি কোটি ছোট object হলে এটি চোখে পড়ে। তিন, সবচেয়ে বড়টি: compiler সাধারণত virtual ডাককে inline করতে পারে না, কারণ কোন ফাংশন চলবে তা সে জানে না। ছোট ফাংশন inline হলে তার চারপাশের কোড একসাথে অপ্টিমাইজ হয়; virtual ডাক সেই সুযোগ কেড়ে নেয়।

বাস্তবে বেশিরভাগ প্রোগ্রামে এই খরচ চোখেই পড়ে না — একটি পেমেন্ট প্রক্রিয়ায় নেটওয়ার্কে যে সময় লাগে, তার তুলনায় virtual ডাক নগণ্য। খরচ টের পাওয়া যায় শুধু খুব ঘন লুপে, যেখানে লাখ লাখ ছোট object-এ ক্ষুদ্র কোনো virtual ফাংশন বারবার ডাকা হয় — যেমন গেম ইঞ্জিন বা সিমুলেশনে। সেখানে মেপে দেখে (পর্ব ৪৯) তবেই বিকল্প ভাবুন। অনুমানে virtual বাদ দেবেন না, মেপে দেখে দেবেন।

৭ · Constructor-এ virtual ডাক, আর covariant return

একটি প্রশ্ন দিয়ে শুরু করুন: base class-এর constructor থেকে একটি virtual ফাংশন ডাকলে কোন সংস্করণ চলবে? উত্তর অনেককে অবাক করে — base-এর সংস্করণ। কারণটা যুক্তিসংগত। derived object তৈরি হয় ভেতর থেকে বাইরে: আগে base অংশ, তারপর derived অংশ (পর্ব ২১ আর ২৪)। base-এর constructor চলার সময় derived-এর সদস্যরা এখনো তৈরিই হয়নি। তখন derived-এর ফাংশন চালাতে দিলে সেটি অপ্রস্তুত ডেটা ছুঁয়ে ফেলত। তাই C++ নিয়ম করেছে: constructor বা destructor চলার সময় object-এর dynamic type ধরা হয় যে class-এর constructor/destructor চলছে, সেটি। একটি বিজ্ঞপ্তি পাঠানোর ছোট উদাহরণে দেখুন — এখানে একটি non-virtual ফাংশনও রাখা আছে, যাতে static binding-ও চোখে দেখা যায়:

#include <print>

struct Notifier {
    Notifier() { std::println("ctor sees: {}", channel()); }  // virtual call in ctor
    virtual ~Notifier() = default;
    virtual const char* channel() const { return "base"; }
    const char* tag() const { return "generic"; }             // NOT virtual
    void send() const { std::println("[{}, {}] sent", channel(), tag()); }
};
struct Sms : Notifier {
    const char* channel() const override { return "SMS"; }
    const char* tag() const { return "sms-tag"; }             // hides, does not override
};

int main() {
    Sms s;
    const Notifier& n = s;
    n.send();
    std::println("direct: {} / via base ref: {}", s.tag(), n.tag());
}

constructor-এর ভেতরে ঠিক কী ঘটে, vptr-এর চোখ দিয়ে দেখুন:

1Sms s;                                  // তৈরি শুরু2  Notifier() { println(channel()); }     // base অংশ আগে3  Sms() { }                             // তারপর derived অংশ4n.send();                               // channel() + tag()5}                                       // ~Sms, তারপর ~Notifier

Covariant return — override-এ একটু নির্দিষ্ট ফেরত-টাইপ

সাধারণত override-এর ফেরত-টাইপ base-এর মতোই হতে হয়। একটি ছাড় আছে: base যদি কোনো class-এর pointer বা reference ফেরত দেয়, derived তার নিজের, আরও নির্দিষ্ট টাইপের pointer বা reference ফেরত দিতে পারে। একে বলে covariant return type.

struct Shape {
    virtual ~Shape() = default;
    virtual Shape* clone() const = 0;       // = 0-এর অর্থ পর্ব ২৬-এ
};
struct Circle : Shape {
    Circle* clone() const override { return new Circle(*this); }  // Shape* নয়, Circle*
};
// কিন্তু unique_ptr<Circle> আর unique_ptr<Shape> covariant নয় —
// smart pointer ফেরত দিতে চাইলে দুই জায়গাতেই std::unique_ptr<Shape> লিখতে হয়।

এর লাভ হলো, কেউ যদি সরাসরি একটি Circle-এর ওপর clone() ডাকেন, তিনি cast ছাড়াই Circle* পান। তবে খেয়াল করুন, এখানে raw new আছে — মালিকানা কে নেবে, তা কোড দেখে বোঝা যায় না। আধুনিক কোডে clone সাধারণত std::unique_ptr<Shape> ফেরত দেয়, আর covariance-এর সুবিধাটুকু ছেড়ে দেয়। ধারণাটি জেনে রাখুন, কিন্তু খুব বেশি দরকার পড়বে না।

৮ · dynamic_cast, polymorphic container আর compile-time বিকল্প

dynamic_cast — “এটা কি আসলে একটি Card?”

কখনো কখনো base pointer হাতে নিয়ে জানতে ইচ্ছা করে, এটি আসলে কোন derived টাইপ। base থেকে derived-এর দিকে নামাকে বলে downcast, আর নিরাপদে করার যন্ত্র dynamic_cast. এটি চলার সময় object-এর টাইপের তথ্য (RTTI) দেখে যাচাই করে:

void audit(const Payment& p) {
    if (auto* c = dynamic_cast<const Card*>(&p)) {   // ভুল টাইপ হলে nullptr
        c->checkChip();                               // শুধু Card-এর ফাংশন
    }
}
// reference-এ cast ব্যর্থ হলে nullptr দেওয়ার উপায় নেই, তাই std::bad_cast ছোড়ে:
// const Card& c = dynamic_cast<const Card&>(p);

dynamic_cast কাজ করে শুধু polymorphic টাইপে — যে class-এ অন্তত একটি virtual ফাংশন আছে। static_cast দিয়েও downcast লেখা যায়, কিন্তু সেটি কিছু যাচাই করে না; ভুল টাইপ হলে undefined behavior. তাই অনিশ্চিত হলে dynamic_cast, আর নিশ্চিত হলে… আসলে প্রশ্নটা অন্যখানে।

নানা টাইপ একসাথে — std::vector<std::unique_ptr<Base>>

polymorphic object-দের একটি তালিকায় রাখতে চাইলে std::vector<Payment> চলবে না — প্রতিটি উপাদান slice হয়ে সাধারণ Payment হয়ে যাবে। raw pointer-এর vector (std::vector<Payment*> আর হাতে new) চলে, কিন্তু কে delete করবে তা অস্পষ্ট, আর একটি exception-ই leak ঘটাতে পারে। আধুনিক উত্তর পর্ব ১৭-এর std::unique_ptr: std::vector<std::unique_ptr<Payment>>, আর object বানানো std::make_unique দিয়ে — ঠিক ৩ নম্বর অংশের কোডে যেমন। vector ধ্বংস হলে প্রতিটি unique_ptr তার object মোছে, আর virtual destructor নিশ্চিত করে যে প্রতিটির আসল টাইপের destructor চলছে। দুটি নিয়ম একসাথে কাজ করে: unique_ptr মালিকানা সামলায়, virtual destructor সঠিক পরিষ্কার নিশ্চিত করে। এক নিয়ম বাদ দিলে অন্যটি একা যথেষ্ট নয়।

যখন virtual-এর দরকার নেই — compile-time বিকল্প (এক ঝলক)

run-time polymorphism-এর আসল শক্তি হলো, টাইপের তালিকা খোলা: যে কেউ, যেকোনো সময়, নতুন derived class যোগ করতে পারে — এমনকি একটি plugin হিসেবে, আপনার কোড আবার compile না করেই। কিন্তু সবসময় এই নমনীয়তা দরকার হয় না। তখন C++-এর কিছু compile-time পথ আছে:

কোনটি কখন? নতুন টাইপ বাইরের কেউ যোগ করবে, বা টাইপ চলার সময় ঠিক হয় (ব্যবহারকারী মেনু থেকে বেছে নেন) — virtual. টাইপের তালিকা ছোট আর আপনার নিয়ন্ত্রণে — std::variant ভাবুন। গতির শেষ বিন্দুটুকু দরকার আর টাইপ compile-এর সময়েই জানা — template বা CRTP. বাকি পর্বগুলোতে এগুলো একে একে আসবে।

৯ · AI-এর যুগে — polymorphic কোডের ভুল ধরা

AI টুল class hierarchy বেশ দ্রুত লিখে দেয়, আর কোড প্রায়ই compile হয়। সমস্যা হলো, polymorphism-এর ভুলগুলোর বড় অংশ compile হয় এবং চলেও — শুধু ভুল ফাংশন চালায়, বা চুপচাপ মেমরি ফেলে রাখে। অনলাইনে C++11-এর আগের প্রচুর কোড আছে, যেখানে override নেই আর হাতে new/delete, তাই AI প্রায়ই সেই রীতি অনুসরণ করে। আরেকটি প্রবণতা: “টাইপ দেখে কাজ” — dynamic_cast-এর শিকল বা enum-এর switch — কারণ সেটি ছোট উদাহরণে সরল দেখায়। সাধারণ ভুলগুলো:

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

• virtual ফাংশনওয়ালা প্রতিটি base class-এ virtual destructor (বা protected non-virtual destructor) আছে
• derived-এর প্রতিটি override-এ override লেখা; -Wsuggest-override দিয়ে compile করে কোনো warning পাইনি
• polymorphic object কোথাও by value পাঠানো বা কপি হচ্ছে না (slicing নেই)
• container-এ std::unique_ptr<Base>, তৈরি std::make_unique দিয়ে; কোডে খোলা new/delete নেই
• dynamic_cast বা টাইপের switch খুঁজেছি — প্রতিটির জন্য জিজ্ঞেস করেছি, এটি virtual ফাংশন দিয়ে করা যেত কি না
• নিজে একটি নতুন derived class যোগ করে দেখেছি: ব্যবহারকারী কোডের কোনো লাইন বদলাতে হয়নি