ডিজাইন নীতি — composition ও SOLID

১ · ভালো ডিজাইন মানে কী — বদলানো সহজ, ভাঙা কঠিন

মডিউল ৪-এ আপনি অনেক যন্ত্র হাতে পেয়েছেন। পর্ব ২০-এ class আর object, পর্ব ২১-এ constructor ও destructor, পর্ব ২২-এ copy ও move, পর্ব ২৩-এ operator overloading, পর্ব ২৪-এ inheritance, পর্ব ২৫-এ virtual ফাংশন আর পর্ব ২৬-এ abstract class ও interface. কিন্তু হাতুড়ি, করাত আর পেরেক থাকলেই ভালো আসবাব বানানো যায় না। কোন যন্ত্র কোথায়, কতটুকু — সেই বিচারবুদ্ধির নাম ডিজাইন। এই পর্ব সেই বিচারবুদ্ধি নিয়ে।

প্রথমে একটি সৎ প্রশ্ন: “ভালো ডিজাইন” কীভাবে মাপবেন? কোড সুন্দর দেখায় কি না, class কয়টি, pattern কয়টি — এগুলো মাপকাঠি নয়। বাস্তব মাপকাঠি একটাই: একটি নতুন চাহিদা এলে কোড বদলাতে কত খরচ, আর বদলাতে গিয়ে অন্য কিছু ভাঙার সম্ভাবনা কত। সফটওয়্যার লেখা হয় একবার, কিন্তু বদলানো হয় শতবার। অনলাইন দোকানে আজ bKash, কাল Nagad, পরশু কিস্তিতে কেনার সুবিধা; আজ ঢাকার ভেতরে ডেলিভারি, কাল সারা দেশে। যে কোড এই বদলগুলো সহজে নিতে পারে, সেটিই ভালো ডিজাইন।

পর্ব ২-এ আপনি দুটি শব্দ শিখেছিলেন, যা এই পর্বের প্রতিটি নীতির পেছনে কাজ করে। coupling — দুটি অংশ একে অপরের ওপর কতটা নির্ভর করে; একটিকে বদলালে অন্যটিকেও বদলাতে হয় কি না। cohesion — একটি অংশের ভেতরের জিনিসগুলো একই উদ্দেশ্যে কতটা একসাথে বাঁধা। লক্ষ্য সবসময় একই: ভেতরে উচ্চ cohesion, বাইরে কম coupling. এই পর্বের প্রতিটি নীতি আসলে এই একটি লক্ষ্যে পৌঁছানোর একেকটি কৌশল।

২ · composition বনাম inheritance — “has-a” আর “is-a”

দুটি class-কে জোড়ার প্রধান দুটি উপায় আছে। inheritance (পর্ব ২৪) বলে is-a সম্পর্ক: “একটি SavingsAccount একটি Account”. composition বলে has-a সম্পর্ক: “একটি Car-এর একটি Engine আছে” — অর্থাৎ Engine হলো Car-এর একটি সদস্য।

class Engine { public: void start(); };

class Car : public Engine { };      // is-a: “গাড়ি একটি ইঞ্জিন” — অর্থহীন
class Car2 {                        // has-a: “গাড়ির একটি ইঞ্জিন আছে” — সত্যি
    Engine engine;                  // composition: সদস্য হিসেবে রাখা
public:
    void start() { engine.start(); }  // কাজটা ইঞ্জিনকে দিয়ে দেওয়া (delegation)
};

প্রথম রূপটিও compile হয়, আর Car থেকে start() ডাকাও যায়। কিন্তু এতে Car-এর বাইরের জগৎ জেনে যায় যে Car “আসলে” একটি Engine — যেকোনো ফাংশন, যে Engine& চায়, সে একটি পুরো Car নিয়ে নেবে। Engine-এর প্রতিটি public ফাংশন Car-এর ঘাড়েও চাপে। আর ইঞ্জিন বদলানো? inheritance compile-এর সময়ে স্থির; একটি Car সারাজীবন একই base class নিয়ে থাকে।

নিয়মটা তাই এমন: inheritance ব্যবহার করুন শুধু তখন, যখন derived class সত্যিই base class-এর জায়গায় সব জায়গায় চলতে পারে — যখন আপনি polymorphism চান (পর্ব ২৫), আর “is-a” কথাটি আচরণের দিক থেকে সত্য। শুধু কোড পুনঃব্যবহারের জন্য inheritance নেবেন না; সেই কাজটি composition আরও পরিষ্কারভাবে করে। ১৯৯৪ সালের বিখ্যাত বই Design Patterns-এর একটি মূল উপদেশ ঠিক এটাই: “class inheritance-এর চেয়ে object composition-কে প্রাধান্য দিন।”

inheritance-এর জট — একটি রাইড-শেয়ারিং অ্যাপ

ধরুন আপনি ঢাকার একটি রাইড-শেয়ারিং অ্যাপের ভাড়ার হিসাব লিখছেন। শুরুতে শুধু দুই ধরনের বাহন — বাইক আর গাড়ি। inheritance দিয়ে শুরু করা স্বাভাবিক মনে হয়। তারপর নতুন চাহিদা আসতে থাকে। নিচের ডায়াগ্রামে দেখুন, প্রতিটি নতুন চাহিদায় class-এর গাছ কীভাবে বাড়ে, আর composition কীভাবে সেই জট খোলে:

              Vehicle
             /       \
          Bike        Car

// fare() প্রতিটিতে আলাদা — সব ঠিকঠাক মনে হচ্ছে

                     Vehicle
        /         |          |         \     ...
 PetrolBike  ElectricBike  PetrolCar  ElectricCar
 GasCNG      ElectricCNG

// প্রতিটি নতুন বাহনে ২টি নতুন class

PetrolBikeNormal     PetrolBikeSurge
ElectricBikeNormal   ElectricBikeSurge
PetrolCarNormal      PetrolCarSurge
ElectricCarNormal    ElectricCarSurge
GasCNGNormal         GasCNGSurge
ElectricCNGNormal    ElectricCNGSurge

// আর বৃষ্টি শুরু হলে চলমান রাইডের class বদলানো যায় না!

Ride  has-a  VehicleType  { Bike | Car | CNG }
      has-a  Engine       { Petrol | Electric }
      has-a  FareRule     { Normal | Surge }

// যেকোনো জোড়া চলার সময় বানানো যায়, আর
// ride.setRule(Surge) — চলমান রাইডেও নিয়ম বদলায়

FareRule { Normal | Surge | StudentDiscount }

// inheritance-এ: আরও ৬টি class (প্রতিটি বাহন × জ্বালানি)
// composition-এ: ১টি নতুন FareRule — অন্য কিছু ছোঁয়া হয়নি

এবার এই নকশাটি সত্যিকারের, চালানো যায় এমন কোডে দেখুন। FareRule একটি ছোট interface (পর্ব ২৬), আর Ride তার একটি std::unique_ptr সদস্য হিসেবে রাখে (পর্ব ১৭) — অর্থাৎ Ride-এর একটি ভাড়ার নিয়ম আছে:

#include <memory>
#include <print>
#include <utility>

struct FareRule {                                  // interface: "kivabe vara"
    virtual ~FareRule() = default;
    virtual int fare(int km) const = 0;
};
struct Normal : FareRule { int fare(int km) const override { return 30 + 25 * km; } };
struct Surge  : FareRule { int fare(int km) const override { return (30 + 25 * km) * 3 / 2; } };

class Ride {                                       // Ride HAS-A FareRule
    std::unique_ptr<FareRule> rule;
public:
    explicit Ride(std::unique_ptr<FareRule> r) : rule(std::move(r)) {}
    void setRule(std::unique_ptr<FareRule> r) { rule = std::move(r); }
    void quote(int km) const { std::println("{} km -> {} taka", km, rule->fare(km)); }
};
int main() {
    Ride car(std::make_unique<Normal>());
    car.quote(8);
    car.setRule(std::make_unique<Surge>());        // rule bodlalo, Ride class noy
    car.quote(8);
}

৩ · S — Single Responsibility: বদলানোর কারণ একটাই

এবার পাঁচটি নীতির একটি পরিবার, যাদের নামের প্রথম অক্ষর মিলে হয় SOLID. প্রথমটি Single Responsibility Principle (SRP): একটি class-এর বদলানোর কারণ থাকা উচিত মাত্র একটি। খেয়াল করুন, নিয়মটা “একটিই কাজ করবে” নয় — “একটিই কারণে বদলাবে”. প্রশ্নটা হলো, কোন কোন মানুষ বা কোন কোন সিদ্ধান্ত এই class-কে বদলাতে বাধ্য করতে পারে।

একটি অনলাইন দোকানের বিক্রির রিপোর্ট দেখুন:

// আগে: এক class, তিনটি বদলের কারণ
class SalesReport {
public:
    int total() const;                    // হিসাব — হিসাব বিভাগ নিয়ম বদলালে বদলায়
    void printAsTable() const;            // দেখানো — ডিজাইনার নকশা বদলালে বদলায়
    void saveToFile(const std::string& path) const;  // সংরক্ষণ — CSV থেকে ডেটাবেসে গেলে বদলায়
};

তিনটি আলাদা দল তিনটি আলাদা কারণে এই একটি class খুলবে। হিসাব বিভাগ VAT-এর নিয়ম বদলাল — আপনি total() ঠিক করতে গিয়ে ভুলে printAsTable()-এর একটি জিনিস ভাঙলেন। দুজন প্রোগ্রামার একই ফাইলে একসাথে কাজ করছেন, git-এ সংঘর্ষ। আর রিপোর্টটি ফাইলে না রেখে ইমেইলে পাঠাতে চাইলে? সেই একই class আবার খুলতে হবে। সমাধান — প্রতিটি কারণকে নিজের ঘর দিন:

// পরে: প্রতিটি class-এর একটি করে বদলের কারণ
struct SalesReport { std::vector<Sale> sales; int total() const; };   // শুধু ডেটা আর হিসাব
class TablePrinter { public: void print(const SalesReport& r) const; }; // শুধু দেখানো
class CsvSaver     { public: void save(const SalesReport& r, const std::string& path) const; };

এখন VAT-এর নিয়ম বদলালে শুধু SalesReport, টেবিলের নকশা বদলালে শুধু TablePrinter. প্রতিটি অংশ আলাদাভাবে পরীক্ষাও করা যায় — হিসাব যাচাই করতে ফাইল তৈরি করতে হয় না। কোন অংশ কোন বিভাগের, তা দেখে বোঝা যায় — এটাই উচ্চ cohesion. পর্ব ১৯-এর মাঝপথের প্রজেক্টে আপনি separation of concerns নামে যা দেখেছিলেন, SRP তারই class-স্তরের রূপ।

৪ · O — Open/Closed: নতুন payment method, পুরোনো কোড অক্ষত

Open/Closed Principle (OCP): কোড নতুন আচরণ যোগের জন্য খোলা (open), কিন্তু সংশোধনের জন্য বন্ধ (closed) থাকবে। শুনতে স্ববিরোধী — খোলা আবার বন্ধ? অর্থটা হলো: নতুন ধরনের জিনিস যোগ করতে আপনি নতুন কোড লিখবেন, কিন্তু যে কোড পরীক্ষিত আর চলছে, তা খুলে বদলাবেন না।

একটি বাংলাদেশি অনলাইন দোকানের checkout ভাবুন। প্রথম সংস্করণে পেমেন্ট নেওয়া হয় একটি switch দিয়ে:

// আগে: প্রতিটি নতুন পদ্ধতিতে এই ফাংশন খুলতে হয়
enum class PayKind { BKash, Nagad, Card, CashOnDelivery };

bool pay(PayKind k, int taka) {
    switch (k) {
        case PayKind::BKash: /* bKash API ডাকো */ return true;
        case PayKind::Nagad: /* Nagad API ডাকো */ return true;
        case PayKind::Card:  /* ব্যাংকের gateway */ return true;
        case PayKind::CashOnDelivery: return true;
    }
    return false;
}

চারটি পদ্ধতি থাকলে এটি একদম ঠিক আছে। সমস্যা শুরু হয় যখন এমন switch কোডের পাঁচ জায়গায় ছড়িয়ে থাকে — পেমেন্ট নেওয়া, রসিদ ছাপা, টাকা ফেরত (refund), ফি হিসাব। নতুন একটি পদ্ধতি যোগ করতে হলে পাঁচটি জায়গাই খুঁজে খুঁজে বদলাতে হয়, আর একটি ভুলে গেলে সেটি চলার সময়ের বাগ। এবার interface-এর পথ:

// পরে: নতুন পদ্ধতি = নতুন class; পুরোনো কোড অক্ষত
struct PaymentMethod {                          // পর্ব ২৬-এর interface
    virtual ~PaymentMethod() = default;
    virtual bool pay(int taka) = 0;
    virtual int  fee(int taka) const = 0;
    virtual std::string name() const = 0;
};
class BKashPay : public PaymentMethod { /* ... */ };
class NagadPay : public PaymentMethod { /* ... */ };

void checkout(PaymentMethod& m, int taka) {   // এই ফাংশন আর কখনো বদলাবে না
    if (m.pay(taka + m.fee(taka))) std::println("paid via {}", m.name());
}

এখন নতুন একটি পদ্ধতি — ধরুন Rocket বা Upay — যোগ করতে কী কী ছুঁতে হয়, ধাপে ধাপে দেখুন। লাল দাগ মানে “এই ফাইল খুলে বদলাতে হবে”:

একটি গুরুত্বপূর্ণ সতর্কতা: OCP সব দিকে একসাথে “খোলা” রাখা যায় না। interface-এর নকশা ঠিক করে দেয় কোন দিকের বদল সস্তা। এখানে নতুন পেমেন্ট পদ্ধতি যোগ সস্তা, কিন্তু সব পদ্ধতিতে একটি নতুন কাজ (ধরুন installment()) যোগ করতে এখন প্রতিটি class খুলতে হবে — ঠিক যেটা switch-এর পথে সহজ ছিল। তাই প্রশ্ন করুন: আমার প্রজেক্টে কোনটা বেশি আসে — নতুন ধরন, নাকি নতুন কাজ? নতুন ধরন বেশি এলে interface; নির্দিষ্ট কয়েকটি ধরন আর নতুন কাজ বেশি এলে enum + switch বা পর্ব ৩৮-এর std::variant.

৫ · L — Liskov Substitution: Square কি সত্যিই একটি Rectangle?

Liskov Substitution Principle (LSP): যেখানে base class চলে, সেখানে যেকোনো derived class বসালেও প্রোগ্রাম ঠিকঠাক চলবে। derived class base class-এর প্রতিশ্রুতি ভাঙতে পারবে না — base যা নিশ্চিত করে, derived-কেও তা নিশ্চিত করতে হবে। পর্ব ২৪-এ আপনি এই প্রশ্নের প্রথম ঝলক দেখেছেন; এবার পুরো গল্প।

গণিতে বর্গক্ষেত্র একটি আয়তক্ষেত্র — চার কোণ সমকোণ, শুধু চার বাহু সমান। তাই প্রথম ভাবনা:

class Rectangle {
protected:
    int w = 0, h = 0;
public:
    virtual ~Rectangle() = default;
    virtual void setWidth(int x)  { w = x; }
    virtual void setHeight(int y) { h = y; }
    int area() const { return w * h; }
};
class Square : public Rectangle {           // “বর্গ একটি আয়ত” — গণিতে সত্য
public:
    void setWidth(int x)  override { w = h = x; }   // বাহু সমান রাখতে দুটিই বদলায়
    void setHeight(int y) override { w = h = y; }
};

void stretch(Rectangle& r) {               // Rectangle-এর প্রতিশ্রুতির ওপর ভরসা
    r.setWidth(5);
    r.setHeight(4);
    assert(r.area() == 20);                 // Square পেলে area 16 — ভেঙে গেল!
}

stretch ফাংশনটি একটি যুক্তিসঙ্গত ধারণা করে: Rectangle-এর প্রস্থ বদলালে উচ্চতা বদলায় না। এটি Rectangle-এর একটি অলিখিত প্রতিশ্রুতি, একটি invariant-এর মতো। Square সেই প্রতিশ্রুতি ভাঙে — setHeight(4) চুপচাপ প্রস্থও বদলে দেয়। compiler কিছু বলে না, কোড compile হয়, কিন্তু Rectangle-এর জন্য লেখা প্রতিটি ফাংশন এখন Square পেলে ভুল ফল দিতে পারে।

শিক্ষাটা গভীর: “is-a” কথাটির বিচার হয় আচরণ দিয়ে, সংজ্ঞা দিয়ে নয়। গণিতের বর্গ কখনো “বদলায়” না, তাই সেখানে সম্পর্কটি ঠিক। কিন্তু বদলানো যায় এমন Square বদলানো যায় এমন Rectangle-এর মতো আচরণ করে না। সমাধান কয়েকটি:

বাস্তব জীবনে LSP ভাঙার চিহ্নগুলো চিনে রাখুন: derived class-এ কোনো virtual ফাংশন throw std::logic_error("not supported") করে; derived class base-এর চেয়ে কড়া শর্ত চায় (base যেকোনো পরিমাণ নেয়, derived শুধু ১০০-এর গুণিতক); বা ব্যবহারকারী কোডে dynamic_cast দিয়ে “এটা কি আসলে Square?” পরীক্ষা করতে হয়। এগুলো দেখলে বুঝবেন — inheritance-এর গাছটি মিথ্যা বলছে।

৬ · I আর D — ছোট interface, আর abstraction-এর ওপর নির্ভরতা

I — Interface Segregation: মোটা interface ভেঙে ছোট করুন

Interface Segregation Principle (ISP): কাউকে এমন ফাংশনের ওপর নির্ভর করতে বাধ্য করবেন না, যা সে ব্যবহারই করে না। অফিসের একটি “সব-এক-সাথে” মেশিনের interface দেখুন:

// আগে: একটি মোটা interface
struct Machine {
    virtual ~Machine() = default;
    virtual void print(const Doc& d) = 0;
    virtual void scan(Doc& d) = 0;
    virtual void fax(const Doc& d) = 0;
};
class CheapPrinter : public Machine {
    void print(const Doc& d) override { /* ঠিক আছে */ }
    void scan(Doc&) override { throw std::logic_error("no scanner"); }  // LSP-ও ভাঙল
    void fax(const Doc&) override { throw std::logic_error("no fax"); }
};

// পরে: ছোট, নির্দিষ্ট interface
struct Printer { virtual ~Printer() = default; virtual void print(const Doc& d) = 0; };
struct Scanner { virtual ~Scanner() = default; virtual void scan(Doc& d) = 0; };
class CheapPrinter2 : public Printer { /* শুধু print */ };
class OfficeCombo : public Printer, public Scanner { /* দুটিই পারে */ };

খেয়াল করুন, মোটা interface সরাসরি LSP ভাঙার দিকে ঠেলে দেয়: যে class একটি কাজ পারে না, তাকে সেই কাজের ভান করতে হয়। আর যে ফাংশন শুধু প্রিন্ট করে, সে এখন Printer& চায় — তার কাছে স্ক্যানার আছে কি না, তা অপ্রাসঙ্গিক। C++-এ একটি class একাধিক interface থেকে আসতে পারে (multiple inheritance), আর শুধু pure virtual ফাংশনের interface থেকে নিলে এতে বিপদ কম। ISP-এর সারকথা: interface বানান ব্যবহারকারীর প্রয়োজন দেখে, বাস্তবায়নকারীর সব ক্ষমতা দেখে নয়।

D — Dependency Inversion: খুঁটিনাটির ওপর নয়, abstraction-এর ওপর নির্ভর করুন

Dependency Inversion Principle (DIP)-এর দুটি অংশ। এক, উঁচু স্তরের কোড (ব্যবসার নিয়ম — “অর্ডার হলে গ্রাহককে জানাও”) নিচু স্তরের কোডের (খুঁটিনাটি — “এই কোম্পানির SMS gateway-তে এই URL-এ request পাঠাও”) ওপর নির্ভর করবে না; দুটিই নির্ভর করবে একটি abstraction-এর ওপর। দুই, সেই abstraction-এর মালিক উঁচু স্তর — interface-টি লেখা হয় ব্যবসার ভাষায়, gateway-এর ভাষায় নয়।

পর্ব ২৬-এ আপনি Notifier-এর মতো interface দেখেছেন। এবার দেখুন, নির্ভরতার তীরগুলো কীভাবে ঘুরে যায় — নামটির “inversion” এখান থেকেই:

  [ OrderService ]        উঁচু স্তর: ব্যবসার নিয়ম
         |
         |  #include "ssl_sms.h"
         v
  [ SslWirelessSms ]      নিচু স্তর: নির্দিষ্ট কোম্পানির API

  [ OrderService ]  ← খুলে বদলাতে হবে
         |
         v
  [ SslWirelessSms ]   [ EmailSender ]?   [ টেস্টের নকল ]?

// প্রতিটি টেস্ট চালালে সত্যি SMS যায়, টাকা কাটে

  [ OrderService ] ───uses───> [ Notifier ]  (interface, OrderService-এর পাশে)

// OrderService এখন কোনো কোম্পানির নাম জানে না

  [ OrderService ] ───uses───> [ Notifier ]
                                  ^     ^     ^
                      implements  |     |     |  implements
                   [ SmsNotifier ] [ EmailNotifier ] [ FakeNotifier ]

// নিচু স্তর এখন উঁচু স্তরের interface-এর দিকে তাকায়

main():
    SmsNotifier sms;        OrderService shop(sms);   // আসল দোকান
    FakeNotifier fake;      OrderService test(fake);  // টেস্ট

// OrderService-এর কোড দুই ক্ষেত্রে হুবহু একই

C++-এ abstraction বানানোর একমাত্র উপায় virtual interface নয়। যদি কোন Notifier ব্যবহার হবে তা compile-এর সময়েই জানা থাকে, তাহলে template দিয়েও একই নির্ভরতা-বিচ্ছেদ পাওয়া যায়, virtual ডাকের খরচ ছাড়াই — এটি পর্ব ২৮-২৯-এ দেখবেন, আর পর্ব ৪০-এর concepts দিয়ে সেই “interface”-এর শর্তও লিখে দেওয়া যায়। ছোট কাজের জন্য একটি std::function বা lambda-ও যথেষ্ট। নীতিটা একই — কোন রূপে লিখবেন, তা প্রয়োজন দেখে।

৭ · DRY, KISS, YAGNI আর Law of Demeter — আর কখন থামবেন

SOLID-এর বাইরেও চারটি ছোট নীতি প্রায় প্রতিদিন কাজে লাগে। এগুলো মুখস্থের জিনিস নয় — কোড রিভিউর সময় মনে মনে করার চারটি প্রশ্ন।

DRY-এর একটি সূক্ষ্মতা জানা জরুরি: DRY মানে একই জ্ঞানের পুনরাবৃত্তি এড়ানো, দেখতে একই রকম কোডের নয়। ধরুন রাইড-শেয়ারিং অ্যাপে বাইকের ন্যূনতম ভাড়া আর পার্সেল ডেলিভারির ন্যূনতম ফি — দুটিই আজ ৩০ টাকা। একটি constant-এ জুড়ে দিলে কাল পার্সেলের ফি বাড়ালে বাইকের ভাড়াও বেড়ে যাবে। দুটি আলাদা ব্যবসায়িক সিদ্ধান্ত, তাই আলাদা থাকাই ঠিক। ভুল জায়গায় DRY coupling তৈরি করে, যা কমানোই ছিল লক্ষ্য।

কখন নীতি প্রয়োগ করবেন না — অতিরিক্ত ডিজাইন

নীতিগুলোর একটি অন্ধকার দিক আছে, যার নাম over-engineering. একজন নতুন উৎসাহী প্রোগ্রামার SOLID শিখে একটি ৩০০ লাইনের টিউশন-ফি হিসাবের প্রোগ্রামে বানিয়ে ফেলেন IFeeCalculatorFactory, AbstractStudentRepository, FeeCalculationStrategyManager — প্রতিটির একটিমাত্র বাস্তবায়ন। কোড এখন বারোটি ফাইলে ছড়ানো, আর একটি ছোট বদলের জন্য পাঁচটি ফাইল খুলতে হয়। নীতি মানতে গিয়ে ঠিক সেই সমস্যাটি তৈরি হলো, যা নীতিগুলো সমাধান করার কথা ছিল: বদল কঠিন।

একটি কার্যকর অভ্যাস হলো “তিনের নিয়ম” (rule of three): প্রথমবার সরাসরি লিখুন; দ্বিতীয়বার একই রকম কিছু লাগলে একটু অস্বস্তি নিয়ে আবার লিখুন; তৃতীয়বার এলে তখন abstraction বানান — কারণ ততক্ষণে আপনি তিনটি বাস্তব উদাহরণ দেখেছেন, আর জানেন আসলে কোনটা বদলায়। ভুল abstraction-এর দাম প্রায়ই পুনরাবৃত্তির দামের চেয়ে বেশি।

৮ · value টাইপ বনাম entity টাইপ — C++-এর নিজস্ব প্রশ্ন

Java বা C#-এ প্রায় সব object একটি reference দিয়ে ধরা হয়, তাই “কপি করলে কী হবে” প্রশ্নটি কম ওঠে। C++-এ ডিফল্ট হলো value semantics — auto b = a; একটি সত্যিকারের কপি বানায় (পর্ব ২২)। তাই C++-এ প্রতিটি class ডিজাইনের শুরুতেই একটি প্রশ্নের উত্তর দিতে হয়: এই টাইপটি কি একটি মান, নাকি একটি পরিচয়?

এই বিভাজন ডিজাইনে বড় সাহায্য করে। Money-কে একটি সাধারণ int-এর বদলে value টাইপ বানালে (টাকা আর পয়সা আলাদা, যোগ-বিয়োগের operator সহ) “টাকার সাথে কিলোমিটার যোগ” ধরনের ভুল compile-এর সময়ে ধরা পড়ে। আর polymorphic entity — যেমন PaymentMethod — কপি করতে দিলে পর্ব ২৫-এর object slicing-এর বিপদ: derived অংশ কেটে বাদ পড়ে। তাই একটি ভালো অভ্যাস: polymorphic base class-এ কপি নিষেধ করুন, আর value টাইপে virtual ফাংশন রাখবেন না। দুটি ভূমিকা এক টাইপে মেশালে প্রায়ই সমস্যা হয়।

struct Money {                       // value: মান দিয়ে চেনা, কপি নিরাপদ
    long long paisa = 0;
    friend Money operator+(Money a, Money b) { return {a.paisa + b.paisa}; }
    friend bool operator==(Money, Money) = default;
};
class Order {                        // entity: পরিচয় দিয়ে চেনা
    int id;
    Money total;
public:
    explicit Order(int i) : id(i) {}
    Order(const Order&) = delete;    // একই অর্ডারের দুটি “আসল” কপি নয়
    Order& operator=(const Order&) = delete;
    int orderId() const { return id; }
};

৯ · কেস স্টাডি — একটি OrderProcessor god class ধাপে ধাপে ভাঙা

এবার সব নীতি এক জায়গায়। ধরুন “দেশি বাজার” নামের একটি ছোট অনলাইন দোকানের প্রথম প্রোগ্রামার তাড়াহুড়োয় সব কাজ একটি class-এ লিখেছিলেন। দুই বছর পর সেটি ১,৫০০ লাইনের। এমন class-কে বলে god class — সে সব জানে, সব করে, আর সবাই তার ওপর নির্ভর করে।

class OrderProcessor {               // সবকিছু এক জায়গায়
public:
    void process(Order& o) {
        // ১. কার্টের দাম, ছাড়ের কুপন, ডেলিভারি চার্জ হিসাব (৩০০ লাইন)
        // ২. স্টকে আছে কি না দেখা, স্টক কমানো (২০০ লাইন)
        // ৩. switch দিয়ে bKash / Nagad / Card / COD পেমেন্ট (৪০০ লাইন)
        // ৪. সরাসরি MySQL-এ অর্ডার সংরক্ষণ (২০০ লাইন)
        // ৫. SSL Wireless-এর API দিয়ে SMS পাঠানো (১৫০ লাইন)
        // ৬. PDF রসিদ তৈরি (২৫০ লাইন)
    }
};

লক্ষণগুলো চেনা: কুপনের নিয়ম বদলালে পেমেন্টের কোড ভাঙে; কোনো টেস্ট চালাতে আসল ডেটাবেস আর আসল SMS লাগে; দুজন প্রোগ্রামার একসাথে এই ফাইলে কাজ করতে পারেন না। পুরোটা একবারে নতুন করে লেখা ঝুঁকিপূর্ণ — তাই refactoring করবেন ছোট ছোট নিরাপদ ধাপে, প্রতি ধাপের পর প্রোগ্রাম চালিয়ে আর টেস্ট করে। নিচে লাল দাগ দেখাবে, কোন দায়িত্বটি এই ধাপে বের করে আনা হচ্ছে:

ফলাফলের একটি ছোট, চালানো যায় এমন সংস্করণ দেখুন। এখানে দামের হিসাব একটি free function, জানানোর কাজ Notifier interface-এর পেছনে, আর OrderService শুধু দুটিকে জোড়া দেয়। একই OrderService একবার আসল SMS দিয়ে, একবার টেস্টের নকল দিয়ে চলছে:

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

int orderTotal(const std::vector<int>& prices) {     // job 1: price only, no I/O
    int t = 0;
    for (int p : prices) t += p;
    return t >= 1000 ? t : t + 60;                     // delivery 60 below 1000
}
struct Notifier {                                      // job 2: tell (interface)
    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
    std::vector<std::string> sent;
    void send(const std::string& msg) override { sent.push_back(msg); }
};
class OrderService {                                   // only coordinates
    Notifier& notifier;
public:
    explicit OrderService(Notifier& n) : notifier(n) {}
    void place(const std::vector<int>& prices) {
        notifier.send(std::format("confirmed, total {} taka", orderTotal(prices)));
    }
};
int main() {
    SmsNotifier sms;   OrderService shop(sms);   shop.place({850, 120, 120});
    FakeNotifier fake; OrderService test(fake);  test.place({10, 10, 10});
    std::println("fake saw {} message: {}", fake.sent.size(), fake.sent.at(0));
}

১০ · AI-এর যুগে — অতিরিক্ত ডিজাইন আর god class চেনা

ডিজাইনের প্রশ্নে AI টুলগুলো সাধারণত দুই চরমে যায়। “একটি enterprise-grade, SOLID-মেনে চলা সিস্টেম লেখো” বললে আসে interface-এর পাহাড়: প্রতিটি class-এর জন্য একটি IThing, একটি ThingFactory, একটি ThingManager — যার বেশিরভাগের একটিমাত্র বাস্তবায়ন। আর কিছু না বলে “একটি অর্ডার প্রসেসিং প্রোগ্রাম লেখো” বললে প্রায়ই আসে একটি বিশাল main বা একটি god class, যেখানে হিসাব, প্রিন্ট আর ফাইল লেখা মেশানো। দুটিই compile হয়, চলেও — সমস্যা দেখা দেয় প্রথম বদলের সময়।

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

• প্রতিটি class-এর জন্য এক বাক্যে বলতে পারি “এটি বদলায় যখন …” — দুটি “এবং” লাগলে class-টি ভাঙার কথা ভেবেছি
• প্রতিটি interface-এর অন্তত দুটি বাস্তবায়ন আছে, বা টেস্টের নকলের জন্য সত্যিই দরকার — নইলে সরিয়ে দিতে বলেছি
• প্রতিটি inheritance-এ যাচাই করেছি: derived class কি base-এর সব প্রতিশ্রুতি রাখে? কোনো override throw "not supported" করে না তো?
• ব্যবসার নিয়ম (দাম, কুপন) কোনো ফাইল, ডেটাবেস বা নেটওয়ার্কের কোড ছোঁয় না — আলাদাভাবে টেস্ট করা যায়
• a.b().c().d() ধরনের লম্বা শিকল খুঁজেছি (Law of Demeter), আর একই সংখ্যা বা নিয়ম একাধিক জায়গায় লেখা কি না (DRY)
• নিজে একটি নতুন feature কল্পনা করেছি (ধরুন Rocket পেমেন্ট) আর গুনেছি কয়টি পুরোনো ফাইল খুলতে হবে — সংখ্যাটা ছোট হলে নকশা ভালো