abstract class ও interface — কাজের চুক্তি লেখা

১ · interface মানে চুক্তি — “কী করতে হবে”, “কীভাবে” নয়

আগের পর্বে আপনি দেখেছেন, একটি base class-এর virtual function-কে derived class নিজের মতো করে override করতে পারে, আর base-এর pointer বা reference দিয়ে ডাকলেও চলে আসল object-এর ফাংশন। এই পর্বে প্রশ্নটা একটু উল্টো দিক থেকে: base class যদি নিজে কাজটা আদৌ না জানে?

ধরুন একটি অনলাইন দোকান অর্ডার নিশ্চিত হলে গ্রাহককে খবর পাঠায়। আজ পাঠায় SMS-এ। কাল ব্যবসায়ী বললেন, “ইমেইলেও পাঠান।” পরশু এল WhatsApp. আর টেস্ট চালানোর সময় তো আসল SMS পাঠানোই যাবে না — প্রতিবার টাকা কাটবে। অর্ডারের কোডের কাছে আসলে একটি কথাই জরুরি: “যে-ই হোক, তাকে একটি বার্তা পাঠাতে পারতে হবে।” কীভাবে পাঠাবে — মোবাইল অপারেটরের সার্ভারে, ইমেইল সার্ভারে, নাকি শুধু খাতায় লিখে রাখবে — সেটা অর্ডারের মাথাব্যথা নয়।

পর্ব ২-এ আপনি শিখেছিলেন, interface হলো একটি object বাইরের দুনিয়াকে যে কাজগুলোর প্রতিশ্রুতি দেয়। এতদিন সেটা ছিল শুধু একটি ধারণা — একটি class-এর public ফাংশনগুলো। আজ সেই প্রতিশ্রুতিকে আলাদা করে লিখে ফেলবেন, একটি নিজস্ব টাইপ হিসেবে, যার ভেতরে কোনো কাজের বিবরণ নেই — আছে শুধু চুক্তির শর্ত। এটাই abstraction-এর সবচেয়ে বিশুদ্ধ রূপ।

২ · pure virtual function আর abstract class

পর্ব ২৫-এর virtual function-এর একটি “ডিফল্ট” শরীর (body) থাকে — derived class override না করলে সেটাই চলে। কিন্তু Notifier-এর জন্য কোনো যুক্তিসঙ্গত ডিফল্ট নেই। “সাধারণভাবে বার্তা পাঠাও” — কোথায়? কীভাবে? এমন ক্ষেত্রে C++ বলতে দেয়: “এই ফাংশন থাকবে, কিন্তু এর শরীর আমি দিচ্ছি না — যে আমাকে উত্তরাধিকার নেবে, সে দেবে।” লেখার উপায় হলো declaration-এর শেষে = 0:

struct Notifier {
    virtual ~Notifier() = default;                    // পর্ব ২৫-এর নিয়ম: base-এ virtual destructor
    virtual void send(const std::string& msg) = 0;   // pure virtual — শরীর নেই, শুধু শর্ত
};

= 0 দেওয়া ফাংশনকে বলে pure virtual function. আর যে class-এ অন্তত একটি pure virtual function আছে (নিজে ঘোষণা করেছে, বা উত্তরাধিকার সূত্রে পেয়ে override করেনি), সেটি একটি abstract class. এর উল্টো, যে class-এর সব virtual function-এর শরীর আছে আর যার object বানানো যায়, তাকে বলে concrete class.

abstract class-এর নিয়ম একটাই, আর সেটা কঠোর: এর object বানানো যায় না। যুক্তিটা সহজ। Notifier n; লিখলে তারপর n.send("hi") ডাকলে কী চলবে? কোনো শরীর তো নেই! তাই compiler প্রশ্নটা উঠতেই দেয় না — object বানানোর চেষ্টাতেই error. কিন্তু pointer বা reference রাখা পুরোপুরি বৈধ, কারণ সেগুলো সবসময় কোনো concrete derived object-কেই দেখাবে। ধাপে ধাপে দেখুন compiler কোথায় রাজি, কোথায় নয়:

1struct Notifier {2    virtual ~Notifier() = default;3    virtual void send(const std::string& m) = 0;4};5struct SmsNotifier : Notifier { void send(const std::string& m) override; };6struct HalfNotifier : Notifier { };        // send লেখেনি7Notifier n;                                // ?8SmsNotifier sms;  Notifier& ref = sms;     // ?9HalfNotifier h;                            // ?10auto p = std::make_unique<Notifier>();      // ?

এই error-টা বিরক্তিকর মনে হতে পারে, কিন্তু আসলে এটা একটি নিরাপত্তা-জাল। চুক্তির একটি শর্ত পূরণ না করেই কেউ যদি object বানাতে পারত, তাহলে প্রোগ্রাম চলার সময় একদিন একটি “শরীরহীন” ফাংশন ডাকা পড়ত। C++ সেই সম্ভাবনাকে compile-এর সময়েই শেষ করে দেয়।

৩ · C++-এ interface — keyword ছাড়াই

Java বা C#-এ interface নামে একটি আলাদা keyword আছে। C++-এ নেই। C++-এ interface একটি রীতি — একটি abstract class, যা কয়েকটি কড়া শর্ত মানে:

• সব সাধারণ ফাংশন pure virtual (= 0) — কোনো কাজের বিবরণ নেই
• একটি public virtual destructor (সাধারণত virtual ~X() = default;)
• কোনো ডেটা member নেই — চুক্তির কোনো অবস্থা (state) থাকে না
• নাম কাজ দিয়ে, প্রযুক্তি দিয়ে নয়: Notifier, Storage, PaymentGateway — TwilioSender বা MySqlThing নয়

C++ Core Guidelines-এও এই কথা আছে (C.121): কোনো base class-কে interface হিসেবে ব্যবহার করলে তাকে “pure abstract class” বানান। অনেকে class-এর বদলে struct লেখেন, যাতে সবকিছু ডিফল্ট public থাকে — দুটোই চলে, পার্থক্য শুধু ডিফল্ট access specifier-এ।

virtual destructor কেন বাধ্যতামূলক

interface-এর পুরো উদ্দেশ্য হলো concrete object-কে interface-এর টাইপ দিয়ে ধরে রাখা — আর অনেক সময় তার মালিকও হওয়া: std::unique_ptr<Notifier> n = std::make_unique<SmsNotifier>();. এখন n ধ্বংস হলে সে Notifier* দিয়ে delete করবে। Notifier-এর destructor virtual না হলে C++ শুধু Notifier অংশের destructor চালানোর চেষ্টা করবে, SmsNotifier-এর নয় — আর standard অনুযায়ী এটা undefined behavior. SmsNotifier-এর ভেতরে যদি একটি নেটওয়ার্ক সংযোগ বা বড় buffer থাকে, সেটা কখনো ফেরত যাবে না, বা আরও খারাপ কিছু ঘটবে। তাই interface-এ virtual destructor লেখা কোনো ঐচ্ছিক ভদ্রতা নয়, নিয়ম। সুখবর: g++-এর -Wall চালু থাকলে নিজের লেখা এমন delete-এ সাধারণত -Wdelete-non-virtual-dtor warning আসে — কিন্তু সব ক্ষেত্রে warning-এর ভরসায় থাকবেন না।

৪ · interface-এর ওপর নির্ভর করা — OrderService জানে না কে বার্তা পাঠায়

এবার চুক্তিটা কাজে লাগানো যাক। OrderService নামে একটি class অর্ডার নেয় আর গ্রাহককে খবর দেয়। সে নিজে কোনো Notifier বানায় না; বরং constructor-এ বাইরে থেকে একটি Notifier& নেয়। যে জিনিসের ওপর একটি class নির্ভর করে (এখানে Notifier), তাকে বাইরে থেকে ঢুকিয়ে দেওয়ার এই কৌশলের নাম dependency injection — শুনতে ভারী, কাজে সরল: “যা লাগবে, constructor-এ চেয়ে নিন।”

#include <print>
#include <string>
struct Notifier {                                  // interface: only the contract
    virtual ~Notifier() = default;
    virtual void send(const std::string& msg) = 0;
};
struct SmsNotifier : Notifier {
    void send(const std::string& msg) override { std::println("[SMS] {}", msg); }
};
struct FakeNotifier : Notifier {                   // for tests: remembers, sends nothing
    std::string last;  void send(const std::string& msg) override { last = msg; }
};
struct OrderService {
    explicit OrderService(Notifier& n) : notifier(n) {}
    void place(int id) { notifier.send("Order " + std::to_string(id) + " confirmed"); }
    Notifier& notifier;                            // which one? it does not know
};
int main() {
    SmsNotifier sms;   OrderService live(sms);   live.place(101);
    FakeNotifier fake; OrderService test(fake);  test.place(202);
    std::println("fake recorded: {}", fake.last);
}

live.place(101) ডাকলে ভেতরে ঠিক কী ঘটে, ধাপে ধাপে দেখুন। পর্ব ২৫-এর vtable-এর গল্পটা এখানে একটি বাস্তব কাজে লাগছে:

notifier.send("Order 101 confirmed");
// OrderService.cpp compile হওয়ার সময় compiler শুধু Notifier-এর
// ঘোষণা দেখেছে। SmsNotifier নামে কিছু আছে কি না, সে জানেই না।

notifier  ──>  [ SmsNotifier object ]
                 vptr ──> ?
// টাইপ লেখা Notifier, কিন্তু মেমরিতে বসে আছে SmsNotifier

[ SmsNotifier object ]
   vptr ──>  SmsNotifier-এর vtable
               [0] ~SmsNotifier
               [1] send  ──>  SmsNotifier::send
// (vtable-এর বিন্যাস compiler-এর নিজস্ব; ছবিটা ধারণা দেওয়ার জন্য)

[SMS] Order 101 confirmed
// Fake দিলে একই slot দেখাত FakeNotifier::send-কে —
// OrderService-এর কোড একই, শুধু object আলাদা।

reference, নাকি unique_ptr — কে মালিক?

উপরের কোডে OrderService একটি Notifier& রাখে, অর্থাৎ সে মালিক নয় — Notifier বেঁচে থাকে main-এ, আর তাকে OrderService-এর চেয়ে বেশি দিন বাঁচতে হবে (পর্ব ১৮-এর lifetime-এর নিয়ম)। যদি চান Notifier-টি OrderService-এর নিজের হোক, তাহলে std::unique_ptr নিন:

class OrderService {
    std::unique_ptr<Notifier> notifier;            // মালিক — সাথে জন্মায়, সাথে মরে
public:
    explicit OrderService(std::unique_ptr<Notifier> n) : notifier(std::move(n)) {}
};
OrderService svc(std::make_unique<SmsNotifier>());   // ডাকার লাইনেই বেছে নেওয়া

এখানেই virtual destructor-এর দাম স্পষ্ট: svc ধ্বংস হলে unique_ptr Notifier* দিয়ে delete করবে, আর শুধু virtual destructor থাকলেই ঠিকঠাক ~SmsNotifier চলবে। নিয়মটা মনে রাখুন: শুধু ব্যবহার করলে Notifier&, মালিক হলে std::unique_ptr<Notifier>.

৫ · বদলে দেওয়া যায় এমন অংশ — Storage, Fake আর টেস্ট

interface-এর সবচেয়ে বড় লাভটা চোখে পড়ে টেস্ট লেখার সময়। ধরুন একটি পরীক্ষার রেজাল্ট-অ্যাপ ছাত্রছাত্রীদের নম্বর জমা রাখে। আসল প্রোগ্রামে নম্বর যায় ডিস্কের ফাইলে। কিন্তু টেস্টে প্রতিবার ফাইল খোলা ধীর, আর এক টেস্টের রেখে যাওয়া ফাইল অন্য টেস্টকে গুলিয়ে দিতে পারে। সমাধান — জমা রাখার কাজটাকে একটি চুক্তি বানান:

struct Storage {
    virtual ~Storage() = default;
    virtual void save(const std::string& key, const std::string& value) = 0;
    virtual std::optional<std::string> load(const std::string& key) const = 0;
};
class FileStorage : public Storage { /* ডিস্কের ফাইলে লেখে-পড়ে (পর্ব ৪৪) */ };
class MemoryStorage : public Storage {                  // টেস্টের জন্য: শুধু মেমরিতে
    std::unordered_map<std::string, std::string> data;
    /* save আর load এই map-এ */
};
class ResultService {
    Storage& store;
public:
    explicit ResultService(Storage& s) : store(s) {}
    void record(const std::string& roll, int marks);   // শুধু Storage চেনে
};

যে class টেস্টে আসল জিনিসের জায়গা নেয়, তার সাধারণ নাম test double — সিনেমায় ঝুঁকির দৃশ্যে নায়কের জায়গায় যেমন “ডাবল” নামেন। এর কয়েকটি রকম আছে: Fake সত্যিই কাজ করে কিন্তু সহজ পথে (MemoryStorage — আসল ডেটাবেস নয়, একটি map); Stub শুধু ঠিক করা উত্তর ফেরত দেয়; Mock মনে রাখে কে কীভাবে ডাকল, যাতে টেস্ট পরে যাচাই করতে পারে। উপরের FakeNotifier আসলে Fake আর Mock-এর মাঝামাঝি। টেস্টিং-এর পুরো গল্প পর্ব ৪৮-এ — এখানে শুধু এটুকু বুঝুন: interface না থাকলে test double বসানোর কোনো জায়গাই থাকে না।

একই OrderService-কে তিন জায়গায় তিনভাবে জোড়া লাগানো দেখুন। প্রতিবার শুধু “জোড়া লাগানোর জায়গা” (সাধারণত main বা টেস্ট ফাইল) বদলায়:

SmsNotifier sms;
OrderService shop(sms);
shop.place(101);        // [SMS] Order 101 confirmed

EmailNotifier mail;     // নতুন ফাইলে নতুন class: send()-এ ইমেইল
OrderService shop(mail);
shop.place(102);        // OrderService-এ হাত দিতে হয়নি

FakeNotifier fake;
OrderService shop(fake);
shop.place(7);
check(fake.last == "Order 7 confirmed");   // মিলিসেকেন্ডে উত্তর

MemoryStorage mem;
ResultService rs(mem);
rs.record("roll-15", 78);
check(mem.load("roll-15") == "78");

নতুন class যোগ হলো          : 3টি (Email, Fake, Memory)
OrderService.cpp-এ পরিবর্তন   : 0 লাইন
ResultService.cpp-এ পরিবর্তন  : 0 লাইন
নতুন করে compile             : শুধু নতুন ফাইল আর জোড়ার জায়গা

৬ · একটি class, দুটি interface — multiple inheritance-এর নিরাপদ রূপ

C++-এ একটি class একাধিক base class থেকে উত্তরাধিকার নিতে পারে — একে বলে multiple inheritance. পর্ব ২৪-এ দেখেছেন, ডেটা-ভরা দুটি base একসাথে নিলে ঝামেলা হয়: একই নামের দুটি member, “diamond” আকারের উত্তরাধিকারে একই base-এর দুটি কপি। কিন্তু base-গুলো যদি ডেটাহীন interface হয়, তাহলে এই ঝামেলার প্রায় সবই উধাও — কারণ ভাগাভাগি করার মতো কোনো অবস্থাই নেই, আছে শুধু প্রতিশ্রুতি। তাই বাস্তবে multiple inheritance-এর সবচেয়ে প্রচলিত আর নিরাপদ ব্যবহার এটাই: একটি concrete class, কয়েকটি interface.

উদাহরণ: একটি ই-কমার্স সাইট বিভিন্ন পেমেন্ট গেটওয়ে “plug-in” হিসেবে লাগায়। সব গেটওয়ে টাকা নিতে পারে, কিন্তু সবাই টাকা ফেরত (refund) দিতে পারে না। তাই দুটি ছোট, আলাদা চুক্তি — একটি বড় চুক্তি নয়:

#include <print>
struct PaymentGateway {                            // interface 1: take money
    virtual ~PaymentGateway() = default;
    virtual void pay(int taka) = 0;
};
struct Refundable {                                // interface 2: give money back
    virtual ~Refundable() = default;
    virtual void refund(int taka) = 0;
};
struct WalletGateway : PaymentGateway, Refundable {   // signs both contracts
    void pay(int taka) override    { std::println("wallet: paid {}", taka); }
    void refund(int taka) override { std::println("wallet: refunded {}", taka); }
};
void checkout(PaymentGateway& g) { g.pay(500); }     // knows only pay()
void cancel(Refundable& r)       { r.refund(200); }  // knows only refund()
int main() {
    WalletGateway w;
    checkout(w);  cancel(w);
    PaymentGateway& p = w;  Refundable& r = w;
    std::println("same address? {}", static_cast<void*>(&p) == static_cast<void*>(&r));
}

ঠিকানা আলাদা কেন, আর তাতে কিছু ভাঙে না কেন — মেমরির ভেতরটা ধাপে ধাপে দেখুন:

w @1000 ┌──────────────────────────────┐
        │ PaymentGateway অংশ: vptr → A │  @1000
        │ Refundable অংশ    : vptr → B │  @1008
        └──────────────────────────────┘
(ঠিকানা উদাহরণমাত্র; বিন্যাস compiler-এর ABI ঠিক করে)

g  ──>  @1000  PaymentGateway অংশ
          vptr → A:  [pay → WalletGateway::pay]
checkout জানে শুধু pay — refund-এর অস্তিত্বই তার কাছে নেই

r  ──>  @1008  Refundable অংশ
          vptr → B:  [refund → WalletGateway::refund]
compiler নিজে থেকেই ঠিকানা 8 বাইট সরিয়ে দিয়েছে (this adjustment)

u ধ্বংস হলে: delete (Refundable*)@1008
   → virtual ~Refundable → আসলে ~WalletGateway
   → ঠিকানা আবার @1000-এ সরিয়ে পুরো object মোছা হয়
virtual destructor না থাকলে: ভুল ঠিকানায় delete — undefined behavior

এই নকশার আরেকটি নাম আছে, পর্ব ২৭-এ শুনবেন: Interface Segregation — “বড় এক চুক্তির চেয়ে ছোট কয়েকটি চুক্তি ভালো।” যে গেটওয়ে refund দেয় না, তাকে জোর করে একটি খালি refund() লিখতে হয় না, যা হয়তো চুপচাপ কিছুই করে না বা চলার সময় exception ছোড়ে।

৭ · তিনটি সূক্ষ্ম বিষয় — pure virtual destructor, NVI আর copy

pure virtual destructor — definition লাগবেই

কখনো একটি base class-কে abstract বানাতে চান, অথচ তার কোনো ফাংশনই pure করার মতো স্বাভাবিক নয়। তখন একটি কৌশল আছে: destructor-কেই pure করে দিন। কিন্তু মনে রাখুন — derived class-এর destructor শেষে সবসময় base-এর destructor ডাকে, তাই pure হলেও base-এর destructor-এর শরীর লিখতেই হবে, class-এর বাইরে:

struct Shape {
    virtual ~Shape() = 0;      // pure — তাই Shape abstract
    std::string color;
};
inline Shape::~Shape() {}      // তবু শরীর লাগবে; না দিলে link error

অদ্ভুত শোনালেও এটি বৈধ: C++-এ একটি pure virtual function-এর definition থাকতে পারে। “pure” মানে শুধু “derived class-কে override করতেই হবে আর এই class-এর object হবে না” — “শরীর নেই” নয়। definition না দিলে compile ঠিকঠাক হয়ে যায়, কিন্তু linker undefined reference to 'Shape::~Shape()' জাতীয় error দেয়। (header-এ লিখলে inline লাগবে, পর্ব ১১-এর ODR-এর কারণে।) সাধারণ কোডে এটা কম লাগে — সাধারণ ফাংশন pure রাখাই বেশি স্বাভাবিক।

NVI — বাইরে non-virtual, ভেতরে virtual

কখনো চান প্রতিটি implementation-এর আগে-পরে একই কাজ হোক — যেমন প্রতিটি রিপোর্ট export-এর আগে log লেখা আর পরে সময় মাপা। public ফাংশন virtual হলে প্রতিটি derived class এই নিয়ম নিজে মানবে, এই ভরসা করতে হয়। বিকল্প হলো NVI (Non-Virtual Interface) রীতি, যেটা Herb Sutter ২০০১ সালের একটি প্রবন্ধে জনপ্রিয় করেন:

class Exporter {
public:
    virtual ~Exporter() = default;
    void exportReport(const Report& r) {     // non-virtual: নিয়ম সবার জন্য এক
        log("start");
        doExport(r);                         // আসল কাজ derived class-এর
        log("done");
    }
private:
    virtual void doExport(const Report& r) = 0;   // private, তবু override করা যায়
};

derived class private virtual function-ও override করতে পারে — C++-এ access আর override আলাদা বিষয়। standard library-তেই এর উদাহরণ আছে: locale-এর facet-গুলোতে public put() ভেতরে ডাকে virtual do_put()-কে। খেয়াল করুন, NVI মানলে class আর “বিশুদ্ধ interface” থাকে না, কারণ তার ভেতরে কাজের কোড আছে। দুটোই বৈধ নকশা; NVI বেছে নিন যখন চুক্তির সাথে কিছু বাধ্যতামূলক নিয়মও চাপাতে চান।

interface কপি করবেন না

interface সবসময় reference বা pointer দিয়ে ব্যবহার হয়, value হিসেবে নয়। কেউ যদি একটি concrete object-কে base টাইপের value-তে কপি করতে চায়, derived অংশ কেটে বাদ পড়ে — একে বলে object slicing (পর্ব ২৫-এ দেখেছেন)। pure abstract class-এর ক্ষেত্রে এমন value বানানোই যায় না বলে বড় ঝুঁকি কম, তবে abstract-নয় এমন polymorphic base-এ Core Guidelines (C.67) পরামর্শ দেয় public copy আর move বন্ধ রাখতে। পর্ব ২২-এর Rule of 0/3/5-এর সাথে এটা মিলিয়ে নিন।

৮ · compile-time interface — template, concepts আর type erasure

এতক্ষণ যা দেখলেন, তা চলার সময়ের (runtime) চুক্তি: কোন implementation চলবে, তা ঠিক হয় প্রোগ্রাম চলার সময়, vtable দিয়ে। C++-এ চুক্তি লেখার আরেকটি বড় পথ আছে — compile-এর সময়ে। সেখানে কোনো base class লাগে না, inheritance লাগে না; লাগে শুধু “এই টাইপে send() ডাকা যায় কি?” — এই প্রশ্নের উত্তর।

template <typename T>
concept CanSend = requires(T n, const std::string& m) { n.send(m); };   // C++20

template <CanSend N>
void placeOrder(N& n, int id) { n.send("Order " + std::to_string(id)); }
// যেকোনো টাইপ, যাতে send(string) আছে — Notifier থেকে উত্তরাধিকার না নিলেও

এখানে চুক্তিটির নাম concept (C++20 থেকে, পুরো গল্প পর্ব ৪০-এ), আর template প্রতিটি টাইপের জন্য আলাদা ফাংশন বানিয়ে নেয় (পর্ব ২৮)। কোন send চলবে, তা compiler আগেই জানে, তাই কোনো vtable লাগে না, আর compiler ফাংশনটি সরাসরি ভেতরে বসিয়ে (inline করে) দিতে পারে। একে বলে static polymorphism.

তৃতীয় পথটি মাঝামাঝি: type erasure. বাইরে থেকে একটি সাধারণ value-টাইপ, ভেতরে যেকোনো জিনিস — আর টাইপটা “মুছে” ফেলা হয়। সবচেয়ে পরিচিত উদাহরণ std::function (পর্ব ৩৪-এ বিস্তারিত):

class OrderService {
    std::function<void(const std::string&)> notify;      // যেকোনো "ডাকা যায়" জিনিস
public:
    explicit OrderService(std::function<void(const std::string&)> f) : notify(std::move(f)) {}
    void place(int id) { notify("Order " + std::to_string(id) + " confirmed"); }
};
OrderService svc([](const std::string& m) { std::println("[SMS] {}", m); });   // lambda-ই চুক্তি মানে

কোনো base class নেই, কোনো inheritance নেই — যেকোনো lambda বা ফাংশন, যার স্বাক্ষর মেলে, চলবে। চুক্তি যখন একটিমাত্র ফাংশন, তখন প্রায়ই এটাই সবচেয়ে হালকা সমাধান। ভেতরে std::function নিজেই একধরনের virtual ডাক ব্যবহার করে, তাই খরচ runtime interface-এর কাছাকাছি।

সহজ নিয়ম: implementation চলার সময় বদলায়, বা আলাদা করে compile করা অংশ (plugin, DLL) থেকে আসে — abstract class. সবকিছু compile-এর সময়েই জানা আর প্রতিটি ন্যানোসেকেন্ড দামি — template আর concept. চুক্তি মাত্র একটি ফাংশনের — std::function. তিনটিই “interface-এর ওপর প্রোগ্রাম করা”; পার্থক্য শুধু চুক্তিটা কোথায় আর কখন যাচাই হয়।

৯ · AI-এর যুগে — interface-এর বাড়াবাড়ি আর ফাঁক

“Clean architecture” বা “enterprise” ধাঁচের প্রচুর কোড দেখে শেখা AI টুল প্রায়ই প্রতিটি class-এর জন্য একটি interface বানিয়ে ফেলে: IUserService আর UserServiceImpl, IConfig আর ConfigImpl — যদিও প্রতিটির implementation মাত্র একটি। একে বলা হয় “interface explosion”. উল্টো দিকেও ভুল হয়: virtual destructor বাদ পড়ে, বা interface-এর মধ্যেই কোনো নির্দিষ্ট প্রযুক্তির নাম ঢুকে যায়। এগুলো compile হয়, চলে — সমস্যা দেখা দেয় পরে, leak বা “বদলানো যায় না” হিসেবে। সাধারণ ভুলগুলো:

AI-এর interface-নকশা যাচাইয়ের চেকলিস্ট

• প্রতিটি interface-এর অন্তত দুটি implementation আছে (আসল + টেস্ট ধরেও) — না থাকলে interface-টা সরিয়ে দেওয়ার কথা ভেবেছি
• প্রতিটি interface-এ virtual destructor আছে
• interface-এর ফাংশনগুলোর স্বাক্ষরে কোনো concrete টাইপ, লাইব্রেরি বা প্রযুক্তির নাম নেই
• client class-এর ভেতরে কোনো concrete implementation-এর নাম, new বা dynamic_cast নেই
• প্রতিটি override-এ override আছে, যাতে স্বাক্ষরের ভুল compiler ধরে
• Fake দিয়ে একটি টেস্ট নিজে চালিয়ে দেখেছি — আসল নেটওয়ার্ক বা ফাইল ছাড়াই service যাচাই হয়