Java inheritance — extends আর super

১ · Inheritance — একটি class আরেকটির বিশেষ ধরন

পর্ব ১৫ থেকে ১৮-এ আপনি class লিখেছেন, constructor দিয়েছেন, field private রেখেছেন। এবার একটি ব্যাংকের সফটওয়্যার ভাবুন। সব account-এর কিছু জিনিস একই — account নম্বর, মালিকের নাম, ব্যালান্স, টাকা জমা, টাকা তোলা। কিন্তু savings account-এ বছর শেষে সুদ যোগ হয়, আর current account-এ ব্যবসায়ীরা ব্যালান্সের চেয়ে কিছু বেশি টাকা তুলতে পারেন (overdraft). দুটি আলাদা class লিখে সাধারণ অংশটি দুবার কপি করবেন? তাহলে জমার নিয়ম বদলালে দুই জায়গায় বদলাতে হবে — পর্ব ১২-এর সেই পুরোনো সমস্যা, এবার class-এর স্তরে।

Java-র সমাধান inheritance. সাধারণ অংশ একবার লিখুন একটি class-এ — Account. তারপর বলুন: “SavingsAccount হলো এক ধরনের Account, সাথে সুদের হিসাব।” যে class থেকে পাওয়া হয়, সে superclass (parent); যে পায়, সে subclass (child). Subclass parent-এর field আর method আপনাআপনি পায়, নিজের নতুন জিনিস যোগ করে, আর চাইলে parent-এর কোনো আচরণ নিজের মতো বদলায়।

পর্ব ০২-এ এই দুই সম্পর্কের নাম শুনেছিলেন: is-a (একটি আরেকটির বিশেষ ধরন) আর has-a (একটি আরেকটিকে অংশ হিসেবে রাখে)। Inheritance শুধু প্রথমটির জন্য। এই পর্বে তিনটি বাস্তব উদাহরণ বারবার আসবে:

UML-এ inheritance আঁকা

কোড লেখার আগে দলগুলো প্রায়ই ছবি আঁকে। Class আর তাদের সম্পর্ক আঁকার মানক ভাষা UML class diagram. Inheritance বোঝাতে child থেকে parent-এর দিকে একটি তীর আঁকা হয়, যার মাথা ফাঁপা ত্রিভুজ। তীরের দিক খেয়াল করুন: child জানে তার parent কে, parent জানে না তার কয়টি child আছে।

                 ┌──────────────┐
                 │    Object    │   (java.lang — সবার চূড়ায়)
                 └──────▲───────┘
                        │
              ┌─────────┴─────────┐
              │      Account      │
              │ - accountNo       │   - মানে private
              │ # balance         │   # মানে protected
              │ + deposit()       │   + মানে public
              │ + withdraw()      │
              └───▲───────────▲───┘
                  │           │
   ┌──────────────┴──┐   ┌────┴──────────────┐
   │ SavingsAccount  │   │  CurrentAccount   │
   │ - rate          │   │ - overdraftLimit  │
   │ + addInterest() │   │ + withdraw()  ⟲   │   ⟲ = override
   └─────────────────┘   └───────────────────┘

এই গাছকে বলে class hierarchy. ওপরে সাধারণ, নিচে বিশেষ। প্রতিটি নিচের class ওপরের সব কিছু পায়, তাই একটি SavingsAccount object-এর কাছে deposit() আছে (Account থেকে), addInterest() আছে (নিজের), আর toString()-ও আছে (Object থেকে, অংশ ৭)।

২ · extends — কী উত্তরাধিকারে আসে, কী আসে না

Syntax একটি শব্দের: class-এর নামের পরে extends আর parent-এর নাম।

class Account {
    private final String accountNo;
    protected double balance;
    Account(String accountNo, double opening) {
        this.accountNo = accountNo;
        this.balance = opening;
    }
    public String getAccountNo() { return accountNo; }
    public void deposit(double amt) { balance += amt; }
}

class SavingsAccount extends Account {
    private final double rate;                 // শুধু SavingsAccount-এর
    SavingsAccount(String no, double opening, double rate) {
        super(no, opening);                    // অংশ ৪-এ বিস্তারিত
        this.rate = rate;
    }
    public void addInterest() { balance += balance * rate; }
}

SavingsAccount-এর ভেতরে deposit বা getAccountNo লেখা নেই, তবু s.deposit(500) আর s.getAccountNo() দুটোই চলে। কিন্তু “পায়” কথাটির সূক্ষ্ম অর্থ আছে। নিচের টেবিলটিই এই অংশের সারকথা:

তৃতীয় সারিটি সবচেয়ে বেশি ভুল বোঝা হয়। “Private field কি inherit হয়?” — ইন্টারভিউতে এর সঠিক উত্তর দুই ভাগে: জায়গা হিসেবে আছে, নাম হিসেবে নেই। Java Language Specification-এর ভাষায় private member subclass-এ “inherit হয় না” — অর্থাৎ নাম ধরে পাওয়া যায় না। কিন্তু প্রতিটি SavingsAccount object-এর ভেতরে accountNo-এর জন্য জায়গা ঠিকই আছে, কারণ Account-এর method-গুলো সেটা ব্যবহার করে। Subclass থেকে সরাসরি ছুঁতে গেলে javac বলে:

Main.java:5: error: accountNo has private access in Account
        return "No: " + accountNo;
                        ^

নিচের ডায়াগ্রামে একটি SavingsAccount object-এর ভেতরটা ধাপে ধাপে দেখুন:

heap
┌─────────────── Account object ───────────────┐
│ accountNo = "A-101"     (private)            │
│ balance   = 5000.0      (protected)          │
└──────────────────────────────────────────────┘
শুধু parent-এর field

heap
┌──────────── একটিই SavingsAccount object ────────────┐
│ ┌── Account অংশ ──────────────────────────────┐     │
│ │ accountNo = "S-202"     (private)           │     │
│ │ balance   = 10000.0     (protected)         │     │
│ └─────────────────────────────────────────────┘     │
│   rate      = 0.05        (SavingsAccount-এর নিজের) │
└─────────────────────────────────────────────────────┘
দুটি object নয় — একটি object, ভেতরে দুই স্তর

SavingsAccount-এর method থেকে:
  balance        ✔  protected — সরাসরি
  rate           ✔  নিজের field
  deposit(...)   ✔  public method, Account থেকে পাওয়া
  getAccountNo() ✔  public method দিয়ে accountNo পড়া
  accountNo      ✘  private — "has private access in Account"
জায়গা আছে, কিন্তু চাবি parent-এর কাছে

heap
┌──────────── CurrentAccount object ──────────────────┐
│ ┌── Account অংশ ─────────────────────────────┐      │
│ │ accountNo = "C-303"                         │      │
│ │ balance   = 2000.0                          │      │
│ └─────────────────────────────────────────────┘      │
│   overdraftLimit = 5000.0    (নিজের)                │
└─────────────────────────────────────────────────────┘
rate এখানে নেই — ভাইবোন একে অপরের কিছু পায় না

একটিই parent — single inheritance

একটি class কি দুটি class extends করতে পারে? ধরুন class StudentEmployee extends Student, Employee. Java-তে এটা syntax-স্তরেই অসম্ভব:

Main.java:3: error: '{' expected
class C extends A, B { }
                 ^

Compiler extends A-এর পরে সরাসরি { আশা করে — কমা দিয়ে দ্বিতীয় নামের কোনো জায়গাই রাখা হয়নি। Java class-এর ক্ষেত্রে single inheritance মানে। কারণটি হলো diamond problem: Student আর Employee দুজনেই যদি Person থেকে আসে আর দুজনেই getId() নিজের মতো লেখে, তাহলে StudentEmployee-এর getId() কোনটা? Person-এর name field কি এক কপি, না দুই কপি? C++ এর উত্তর দেয় virtual inheritance-এর মতো জটিল নিয়ম দিয়ে; Java প্রশ্নটাই বাদ দিয়েছে। “একাধিক ধরন” প্রকাশ করার দরকার হলে Java-তে আছে interface — একটি class অনেকগুলো interface implement করতে পারে, কারণ interface-এ object-এর অবস্থা (field) থাকে না। সেটা পর্ব ২১-এ।

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

পর্ব ১৭-এ চারটি access level দেখেছেন। Inheritance-এ এসে protected-এর অর্থ পরিষ্কার হয়। Java-তে protected-এর অর্থ অনেকে যা ভাবেন তার চেয়ে বেশি খোলা:

খেয়াল করুন দ্বিতীয় কলাম: protected member একই package-এর সব class ব্যবহার করতে পারে, subclass হোক বা না হোক। C++-এর protected শুধু subclass-এর জন্য; Java-রটা “package + subclass”. তাই protected মানে “শুধু পরিবারের জন্য” নয় — “পরিবার আর পুরো পাড়া”।

Protected field — সুবিধা না ফাঁদ?

অংশ ২-এর কোডে balance protected রাখা হয়েছিল, যাতে SavingsAccount সরাসরি balance += … লিখতে পারে। সুবিধাজনক, কিন্তু ভাবুন: Account-এর একটি নিয়ম (invariant) আছে — “ব্যালান্স কখনো ঋণাত্মক হবে না”। withdraw() এটা পাহারা দেয়। এখন যে কেউ একটি subclass লিখে balance = -1_000_000; করতে পারে, কোনো পাহারা ছাড়াই। আর একই package-এর যেকোনো class-ও পারে। একটি protected field মানে আপনার class-এর নিয়ম এখন অসংখ্য অজানা class-এর সততার ওপর নির্ভর করছে।

class Account {
    private double balance;                       // field private-ই থাকুক
    protected void addToBalance(double amt) {     // subclass-এর জন্য নিয়ন্ত্রিত দরজা
        if (balance + amt < 0) throw new IllegalStateException("negative balance");
        balance += amt;
    }
    public double getBalance() { return balance; }
}

৪ · Constructor আর super(...) — আগে parent, পরে child

Subclass parent-এর method পায়, কিন্তু constructor পায় না। কারণ সহজ: constructor-এর কাজ তার নিজের class-এর field গোছানো। Account-এর constructor জানে না SavingsAccount-এর rate আছে। তাই প্রতিটি class নিজের constructor লেখে। কিন্তু Account অংশটি (অংশ ২-এর ধাপ ২) কে গোছাবে? Account নিজেই — আর সেজন্য Java-র কড়া নিয়ম:

এই ডাক লেখা হয় super(...) দিয়ে। Java 21-এ এটি অবশ্যই constructor-এর প্রথম statement হতে হবে। আগে অন্য কিছু লিখলে:

Main.java:7: error: call to super must be first statement in constructor
        super(opening);
             ^

যুক্তিটা হলো: child-এর কোড চলার আগে parent অংশ সম্পূর্ণ তৈরি থাকতে হবে, যাতে child নিশ্চিন্তে parent-এর method ডাকতে পারে। (Java 22–24-এ preview হিসেবে পরীক্ষার পর Java 25-এ JEP 513 এই নিয়ম কিছুটা শিথিল করেছে — super(...)-এর আগে argument যাচাইয়ের মতো কিছু statement লেখা যায়, তবে তখনো তৈরি হতে থাকা object-টিকে (যেমন তার method ডাকা) ব্যবহার করা যায় না। এই কোর্সে আমরা Java 21 ধরে চলি, যেখানে পুরোনো নিয়মই খাটে।)

লুকানো super() — আর তার বিখ্যাত error

আপনি super(...) না লিখলে compiler নিজে প্রথম লাইনে super(); বসিয়ে দেয় — parameter-হীন parent constructor-এর ডাক। আর কোনো constructor-ই না লিখলে compiler একটি default constructor বানায়, যার ভেতরে শুধু ওই super();. সমস্যা হয় তখন, যখন parent-এ parameter-হীন constructor নেই:

class Account {
    protected double balance;
    Account(double opening) { balance = opening; }   // শুধু এটাই
}
class SavingsAccount extends Account {
    SavingsAccount() {                                // এখানে লুকানো super();
        System.out.println("savings");
    }
}

Main.java:6: error: constructor Account in class Account cannot be applied to given types;
    SavingsAccount() {
                     ^
  required: double
  found:    no arguments
  reason: actual and formal argument lists differ in length
1 error

Error-টি পড়তে শিখুন, কারণ নতুনদের কাছে এটা রহস্যময় লাগে — আপনি তো Account(...) কোথাও ডাকেননি! ডেকেছে compiler, লুকিয়ে: super(). মেসেজ বলছে, Account-এর constructor চায় একটি double (required), কিন্তু পেয়েছে কিছুই না (found: no arguments). Subclass-এ কোনো constructor না লিখলেও একই error আসে, তখন তীরচিহ্ন class-এর লাইনে। সমাধান দুটির একটি: subclass-এর constructor-এ নিজে super(0) বা super(opening) লিখুন, অথবা — যদি অর্থপূর্ণ হয় — Account-এ একটি parameter-হীন constructor যোগ করুন। ব্যাংক account-এর ক্ষেত্রে প্রথমটিই ঠিক: শুরুর ব্যালান্স ছাড়া account খোলার মানে নেই।

এবার সব একসাথে চালিয়ে দেখুন — constructor-এর ক্রম, inherited method, নিজের method আর override:

class Account {
    protected double balance;
    Account(double opening) { balance = opening; System.out.println("1. Account"); }
    void deposit(double amt) { balance += amt; }
    String info() { return "Balance: " + balance; }
}
class SavingsAccount extends Account {
    private final double rate;
    SavingsAccount(double opening, double rate) {
        super(opening);                  // সবার আগে parent অংশ
        this.rate = rate; System.out.println("2. SavingsAccount");
    }
    void addInterest() { balance += balance * rate; }
    @Override String info() { return super.info() + " (savings)"; }
}
class Main {
    public static void main(String[] args) {
        var s = new SavingsAccount(10000, 0.05);
        s.deposit(2000);  s.addInterest();   // প্রথমটি Account-এর, দ্বিতীয়টি নিজের
        System.out.println(s.info());
    }
}

Hierarchy তিন স্তরের হলে কী হয়? প্রতিটি constructor ওপরেরটিকে ডাকে, সেটি আবার তার ওপরেরটিকে — শেষে Object-এ গিয়ে থামে। একে বলে constructor chaining. ডাক যায় নিচ থেকে ওপরে, কিন্তু শরীর চলে ওপর থেকে নিচে। ধাপে ধাপে দেখুন:

1class Vehicle {2  Vehicle(String route) {3    // লুকানো super() → Object()4    System.out.println("Vehicle " + route);5  }6}7class Bus extends Vehicle {8  Bus(String route) {9    super(route);10    System.out.println("Bus");11  }12}13class AcBus extends Bus {14  AcBus() {15    super("Dhaka-Sylhet");16    System.out.println("AcBus");17  }18}19new AcBus();   // main-এ

৫ · Method overriding আর @Override

CurrentAccount-এ টাকা তোলার নিয়ম আলাদা: ব্যালান্সের চেয়ে বেশি, overdraft সীমা পর্যন্ত তোলা যায়। Account-এর withdraw এখানে ভুল আচরণ করবে। সমাধান — CurrentAccount-এ একই method হুবহু একই signature-এ নতুন করে লেখা। একে বলে method overriding:

class Account {
    protected double balance;
    Account(double opening) { balance = opening; }
    public boolean withdraw(double amt) {
        if (amt > balance) return false;          // ব্যালান্সের বেশি নয়
        balance -= amt;
        return true;
    }
}
class CurrentAccount extends Account {
    private final double overdraftLimit;
    CurrentAccount(double opening, double limit) { super(opening); overdraftLimit = limit; }

    @Override
    public boolean withdraw(double amt) {
        if (amt > balance + overdraftLimit) return false;   // সীমা পর্যন্ত চলবে
        balance -= amt;
        return true;
    }
}

এখন new CurrentAccount(2000, 5000).withdraw(6000) চলে (ব্যালান্স হয় −4000), কিন্তু একটি সাধারণ Account বা SavingsAccount-এ একই ডাক false দেয়। একই নামের ডাক, object অনুযায়ী আলাদা কাজ — এটাই polymorphism-এর বীজ, পরের পর্বে যার পুরো গল্প।

Overloading (পর্ব ১২) থেকে পার্থক্য মনে রাখুন: overloading হলো ভিন্ন parameter-তালিকায় একই নাম, overriding হলো হুবহু একই method signature — নাম আর parameter টাইপ — subclass-এ।

Method খোঁজা হয় কীভাবে

s.deposit(…) ডাকলে JVM বোঝে কীভাবে কোন কোড চালাতে হবে? নিয়মটি সহজ: object-এর আসল class থেকে খোঁজ শুরু, না পেলে এক ধাপ ওপরে, তারপর আরও ওপরে — Object পর্যন্ত। প্রথম যেখানে পাওয়া যায়, সেটাই চলে। নিচে একটি SavingsAccount object-এ পাঁচটি ডাক:

1class Object {  // সরলীকৃত2  String toString() { … }3}4class Account {5  void deposit(double a) { … }6  String info() { … }7}8class SavingsAccount extends Account {9  void addInterest() { … }10  @Override String info() {11    return super.info() + "…"; }12}

super.method() — বদলানো নয়, বাড়ানো

অনেক সময় parent-এর কাজ পুরো বাদ দিতে চান না, তার ওপর কিছু যোগ করতে চান। Manager-এর বেতন = সাধারণ কর্মীর বেতন + বোনাস:

class Employee {
    private final double basic;
    Employee(double basic) { this.basic = basic; }
    public double monthlySalary() { return basic + basic * 0.5; }   // মূল + ভাতা
}
class Manager extends Employee {
    private final double bonus;
    Manager(double basic, double bonus) { super(basic); this.bonus = bonus; }
    @Override
    public double monthlySalary() { return super.monthlySalary() + bonus; }
}

ভাতার নিয়ম বদলালে Employee-তে একবার বদলালেই Manager-ও নতুন হিসাব পাবে, কারণ Manager হিসাবটি কপি করেনি, super.monthlySalary() দিয়ে ডেকেছে। খেয়াল করুন, Manager basic সরাসরি ছোঁয় না — সেটা private, আর দরকারও নেই।

@Override — এক লাইনের বিমা

ওপরের সব override-এ @Override লেখা। এটি একটি annotation — compiler-এর জন্য একটি ঘোষণা: “আমি parent-এর কোনো method override করছি বলে দাবি করছি, মিলিয়ে দেখো।” বাধ্যতামূলক নয়, তবু কেন প্রতিবার লিখবেন, নিচের ঘটনাটিতে দেখুন:

class Bus extends Vehicle {
    private final String route = "Dhaka-Ctg";
    public String tostring() {
        return "Bus: " + route;
    }
}
System.out.println(bus);
আশা: Bus: Dhaka-Ctg

$ javac Main.java      (কোনো error, কোনো warning নেই)
$ java Main
Bus@4e25154f
tostring() একটি নতুন method — toString()-কে কেউ ছোঁয়নি,
তাই Object-এর ডিফল্ট toString চলল (সংখ্যাটি প্রতিবার আলাদা হতে পারে)

    @Override
    public String tostring() { ... }

Main.java:3: error: method does not override or implement
a method from a supertype
    @Override
    ^
1 error

    @Override
    public String toString() {
        return "Bus: " + route;
    }

$ java Main
Bus: Dhaka-Ctg

৬ · Overriding-এর নিয়ম, final আর hiding

Override করা method parent-এর প্রতিশ্রুতি ভাঙতে পারবে না — কারণ যে কোড parent টাইপ নিয়ে কাজ করে, সে child object পেলেও একই আচরণ আশা করে। Java এই প্রতিশ্রুতি compiler দিয়ে পাহারা দেয়। প্রতিটি error নিচে OpenJDK 21-এ যাচাই করা:

দ্বিতীয় সারির ছাড়টির নাম covariant return type (Java 5 থেকে)। Vehicle-এ Vehicle copy() থাকলে Bus সেটাকে Bus copy() দিয়ে override করতে পারে — Bus তো একটি Vehicle-ই, তাই Vehicle চাওয়া caller কোনো অসুবিধায় পড়ে না, আর Bus-এর সাথে কাজ করা caller cast ছাড়াই Bus পায়। Visibility বাড়ানো যায় (protected → public), কমানো যায় না — একই যুক্তিতে।

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

পর্ব ১৮-এ final ভ্যারিয়েবল দেখেছেন। একই শব্দ method আর class-এও বসে, অর্থ একই — আর বদলানো যাবে না:

• final method — কোনো subclass override করতে পারবে না। যেমন Account-এর final boolean verifyPin(...): নিরাপত্তা-যাচাইয়ের নিয়ম কোনো subclass নিজের মতো ঢিলে করতে পারবে না।
• final class — কেউ extends-ই করতে পারবে না। Java-র String, Integer আর অন্য wrapper class, Math সবাই final. String final না হলে কেউ একটি “String” subclass বানিয়ে immutability ভেঙে দিতে পারত — আর String-এর ওপর নির্ভর করা নিরাপত্তা-কোড (ফাইলের path, class-এর নাম) বিপদে পড়ত। চেষ্টা করলে: error: cannot inherit from final Account.

পর্ব ২৫-এর record সবসময় final, আর পর্ব ২৪-এর enum-কেও বাইরের কোনো class extends করতে পারে না। আর পর্ব ২৬-এ দেখবেন sealed — “সবার জন্য বন্ধ নয়, শুধু এই কয়েকটি নির্দিষ্ট class extends করতে পারবে” — final আর খোলা class-এর মাঝামাঝি একটি পথ।

Overriding, overloading আর hiding — তিন ভাই

class Vehicle {
    static String type() { return "Vehicle"; }
    String name = "vehicle";
    String name() { return name; }
}
class Bus extends Vehicle {
    static String type() { return "Bus"; }      // hiding, override নয়
    String name = "bus";                         // field-ও শুধু আড়াল করে
    @Override String name() { return name; }     // আসল override
}

Vehicle v = new Bus();
v.name();     // "bus"      — instance method: object-এর আসল class দেখে
v.name;       // "vehicle"  — field: ভ্যারিয়েবলের ঘোষিত টাইপ দেখে
Vehicle.type() + " " + Bus.type();   // "Vehicle Bus"

এখানে v-এর ঘোষিত টাইপ Vehicle, কিন্তু ভেতরে আছে একটি Bus. Instance method override হয়, তাই চলার সময় আসল object (Bus) দেখে Bus-এর name() চলে। কিন্তু field আর static method polymorphic নয় — এগুলো compile-এর সময় ঘোষিত টাইপ দেখে ঠিক হয়। Subclass-এ একই নামের static method লিখলে তাকে বলে method hiding; একই নামের field লিখলে field hiding. দুটিই বিভ্রান্তিকর, বাস্তব কোডে এড়িয়ে চলুন — static method সবসময় class-এর নাম দিয়ে ডাকুন (Bus.type()), আর subclass-এ parent-এর field-এর নাম আবার ব্যবহার করবেন না। (পুরো উদাহরণটি চালিয়ে আউটপুট যাচাই করা।)

৭ · Object — সবার পূর্বপুরুষ, আর hierarchy কত গভীর হবে

যে class-এ extends লেখা নেই, সেটাও আসলে একটি subclass. Compiler নীরবে ধরে নেয় extends Object. java.lang.Object তাই Java-র সব class-এর মূল — String, ArrayList, আপনার Account, সবার। এজন্য যেকোনো object-এর কাছে কয়েকটি method সবসময় থাকে:

• toString() — object-এর লেখারূপ; ডিফল্টে class-এর নাম আর একটি hex সংখ্যা, যা প্রায় কোনো কাজের নয়, তাই প্রায় সব class এটা override করে।
• equals(Object) আর hashCode() — দুটি object “সমান” কি না; ডিফল্টে ==-এর মতো, অর্থাৎ একই object কি না।
• getClass() — object-এর আসল class (এটা final, override করা যায় না)।

এগুলো কীভাবে ঠিকমতো override করতে হয় — বিশেষ করে equals আর hashCode-এর জোড়া চুক্তি — পর্ব ২৩-এর পুরো বিষয়। আপাতত মনে রাখুন: System.out.println(anyObject) কাজ করে কারণ প্রতিটি object-এর কাছে Object থেকে পাওয়া toString() আছে। আর new Bus() instanceof Object সবসময় true.

কত স্তর পর্যন্ত গভীর?

Inheritance শিখে অনেকের প্রথম ঝোঁক হয় সব কিছুকে একটি বিশাল গাছে সাজানো: Vehicle → MotorVehicle → PassengerVehicle → Bus → AcBus → VolvoAcBus… প্রতিটি স্তর বোঝার জন্য তার ওপরের সব স্তর বুঝতে হয়, আর একটি method কোথায় লেখা আছে তা খুঁজতে পাঁচটি ফাইল খুলতে হয়। ওপরের কোনো class-এ একটি বদল নিচের সবগুলোকে প্রভাবিত করে। বাস্তব অভিজ্ঞতা থেকে একটি মোটামুটি নিয়ম: নিজের কোডে দুই-তিন স্তরের বেশি গভীর hierarchy হলে থেমে ভাবুন। প্রায়ই দেখা যায় কিছু “স্তর” আসলে একটি field (যেমন hasAc) বা একটি আলাদা object (composition) হওয়া উচিত ছিল।

৮ · Composition over inheritance — কখন extends করবেন না

Inheritance শক্তিশালী, কিন্তু এর একটি লুকানো দাম আছে: subclass parent-এর ভেতরের কাজের ধরনের সাথে বাঁধা পড়ে যায়। Parent কোন method ভেতরে কোন method ডাকে, সেটা parent-এর ব্যক্তিগত ব্যাপার — কিন্তু subclass সেটার ওপর নির্ভর করে ফেলে, প্রায়ই না জেনে। নিচের উদাহরণটি Joshua Bloch-এর Effective Java বইয়ের একটি বিখ্যাত উদাহরণের সরল রূপ। লক্ষ্য: একটি set-এ মোট কতবার কিছু যোগ করার চেষ্টা হয়েছে, গোনা।

import java.util.*;
class CountingSet extends HashSet<String> {          // inheritance
    int added = 0;
    @Override public boolean add(String s) { added++; return super.add(s); }
    @Override public boolean addAll(Collection<? extends String> c) {
        added += c.size(); return super.addAll(c);
    }
}
class CountingSet2 {                                  // composition
    private final Set<String> set = new HashSet<>();
    int added = 0;
    boolean add(String s) { added++; return set.add(s); }
    boolean addAll(Collection<String> c) { added += c.size(); return set.addAll(c); }
}
class Main {
    public static void main(String[] args) {
        var a = new CountingSet();  a.addAll(List.of("Dhaka", "Khulna", "Sylhet"));
        var b = new CountingSet2(); b.addAll(List.of("Dhaka", "Khulna", "Sylhet"));
        System.out.println("extends HashSet : added = " + a.added);
        System.out.println("has-a HashSet   : added = " + b.added);
    }
}

এই ঘটনার নাম fragile base class problem: parent class-এর এমন বদল বা ভেতরের আচরণ, যা তার নিজের জন্য সম্পূর্ণ ঠিক, কিন্তু subclass ভেঙে দেয়। আর সমাধানের নাম composition: extends না করে, অন্য object-কে field হিসেবে রাখুন (has-a), আর তার কাজ ব্যবহার করুন। CountingSet2-এর add আর addAll হলো forwarding method — কাজটা ভেতরের set-কে পাঠিয়ে দেয়, সাথে নিজের গণনা যোগ করে। এই “মুড়ে দিয়ে ক্ষমতা যোগ” নকশাটি পর্ব ০৯-এ দেখা decorator pattern-এর আত্মীয়।

JDK-র নিজের ভুল: Stack extends Vector

Java-র নির্মাতারাও এই ফাঁদে পড়েছিলেন। ১৯৯৬ সালের JDK 1.0-তে java.util.Stack লেখা হয় Vector-এর subclass হিসেবে — কোড পুনর্ব্যবহারের সহজ পথ। কিন্তু stack মানে শুধু ওপরে রাখা আর ওপর থেকে তোলা (LIFO); Vector হলো যেকোনো জায়গায় ঢোকানো-বের করা যায় এমন তালিকা। Inheritance-এর ফলে Stack-এর ওপর Vector-এর সব public method চলে আসে: stack.add(0, x) দিয়ে stack-এর তলায় ঢোকানো যায়, stack.get(3) দিয়ে মাঝখান থেকে পড়া যায়। “Stack is-a Vector” — সত্যি নয়। একই ভুল Properties extends Hashtable-এ। আজ Stack-এর Javadoc নিজেই বলে LIFO-র জন্য Deque interface আর তার implementation (যেমন ArrayDeque) ব্যবহার করতে (পর্ব ৩২)। কিন্তু Stack মুছে ফেলা যায় না — লাখো পুরোনো প্রোগ্রাম এর ওপর নির্ভর করে। Inheritance-এর ভুল সংশোধন করা কঠিন, কারণ এটা একটি public প্রতিশ্রুতি।

কখন extends, কখন composition — একটি ছোট পরীক্ষা

• “B কি সত্যিই এক ধরনের A?” — বাক্যটি জোরে বলে দেখুন। SavingsAccount is an Account ✔; Stack is a Vector ✘; Car is an Engine ✘ (Car has an Engine).
• A-এর প্রতিটি public method কি B-তেও অর্থবহ? একটিও অর্থহীন হলে (Stack-এ add(0, x)) — composition.
• যেখানে A চলে, সেখানে B বসালে কি সব আগের মতো ঠিক থাকে? (ভাবনার প্রশ্ন ৪-এর Liskov নিয়ম)
• A কি আপনার নিজের, একই দলের, নাকি অন্যের library? অন্যের class extends করা মানে তার ভেতরের আচরণের ওপর বাজি ধরা।
• শুধু কিছু method-এর কোড পুনর্ব্যবহারের জন্য extends করছেন? তাহলে প্রায় নিশ্চিতভাবে composition.

৯ · AI-এর যুগে — inheritance গাছ ছাঁটা আপনার কাজ

AI-কে “একটি বাস কোম্পানির টিকিট সিস্টেম Java-তে বানিয়ে দাও” বললে প্রায়ই সুন্দর দেখতে একটি বিশাল class গাছ আসে — BaseEntity → AbstractVehicle → MotorVehicle → Bus → AcBus — প্রতিটি স্তরে কয়েকটি protected field. দেখতে “পেশাদার”, কিন্তু প্রথম বদলেই ভাঙে। AI ইন্টারনেটের লাখো টিউটোরিয়াল থেকে শিখেছে, আর পুরোনো টিউটোরিয়ালে inheritance-কে প্রায়ই কোড পুনর্ব্যবহারের প্রধান উপায় হিসেবে দেখানো হতো।

AI-এর লেখা class গাছ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি extends-এর জন্য “B is a A” বাক্যটি সত্য, আর A-এর সব public method B-তেও অর্থবহ
• Hierarchy-র গভীরতা গুনেছি; অপ্রয়োজনীয় “Base”, “Abstract” স্তর নেই
• প্রতিটি override-এ @Override আছে — একটি সরিয়ে বানান ভুল করে দেখেছি compiler ধরে কি না
• কোনো protected বা public field দিয়ে parent-এর নিয়ম (যেমন ঋণাত্মক ব্যালান্স নয়) ভাঙা যায় না
• Constructor থেকে কোনো overridable method ডাকা হচ্ছে না
• JDK বা অন্য library-র class (যেমন HashSet, ArrayList) extends করা থাকলে, composition দিয়ে লেখা যায় কি না ভেবেছি