equals, hashCode, toString আর compareTo — Object-এর চুক্তি

১ · সবার উত্তরাধিকার — Object-এর কয়েকটি method

পর্ব ১৯-এ দেখেছেন, যে class-এ extends লেখা নেই, সেটাও আসলে java.lang.Object-এর subclass. তাই আপনার লেখা প্রতিটি class — Student, Book, Product — জন্ম থেকেই কয়েকটি method নিয়ে আসে। এতদিন এগুলো চুপচাপ পড়ে ছিল। কিন্তু Java-র বাকি অংশ, বিশেষ করে collection, এগুলোর ওপর অন্ধভাবে ভরসা করে। System.out.println(student) লিখলে println নিজে student-এর toString() ডাকে। list.contains(book) লিখলে ArrayList প্রতিটি উপাদানের সাথে equals() ডাকে। HashSet-এ কিছু রাখলে সে আগে hashCode() চায়।

অর্থাৎ এই method-গুলো আপনার class আর Java library-র মধ্যে একটি চুক্তি। Library ধরে নেয় আপনি নিয়ম মেনে লিখেছেন। নিয়ম ভাঙলে compiler কিছু বলে না, প্রোগ্রাম crash-ও করে না। শুধু HashSet-এ একই ছাত্র দুবার থাকে, লাইব্রেরির খোঁজে বই পাওয়া যায় না, sort-এর ক্রম মাঝে মাঝে উল্টে যায়। এই ধরনের নীরব bug খুঁজে পেতে দিন লেগে যায়। এই পর্বের লক্ষ্য তাই একটাই: চুক্তিগুলো বোঝা, যাতে নিজে লিখুন বা AI লিখুক, ভুলটা আপনি দেখতে পান।

Object-এর public আর protected method-গুলোর পুরো তালিকা ছোট। কোনটি নিয়ে এই পর্বে কতটা কাজ, নিচের টেবিলে দেখুন:

compareTo এই তালিকায় নেই — সেটা Object-এর নয়, আসে Comparable interface থেকে (অংশ ৭)। তবু এটাকে একই পরিবারে রাখা হয়, কারণ এরও একটি চুক্তি আছে আর সেটা equals-এর সাথে মিলতে হয়। Joshua Bloch তাঁর Effective Java বইয়ের একটি পুরো অধ্যায় (“Methods Common to All Objects”) এই চারটি আর clone নিয়ে লিখেছেন — Java-র পেশাদার জগতে এই অধ্যায়ের নিয়মগুলো প্রায় আইনের মতো মানা হয়।

এই পর্বে চারটি বাস্তব উদাহরণ বারবার আসবে:

২ · toString — object-এর পড়ার মতো পরিচয়

সবচেয়ে সহজটি দিয়ে শুরু। toString() override না করে একটি Student ছাপলে যা পান, তার আকার এমন:

Student@(একটি hex সংখ্যা — প্রতিবার আলাদা হতে পারে)

Object-এর সংস্করণটি আসলে getClass().getName() + "@" + Integer.toHexString(hashCode()) ফেরত দেয়। Class-এর নামটুকু ছাড়া এতে কাজের কিছু নেই। সংখ্যাটি object-এর ঠিকানা নয় (অনেকে তাই ভাবেন) — সেটা ডিফল্ট hashCode, যা প্রতিবার প্রোগ্রাম চালালে বদলাতে পারে। একটি সমস্যার log-এ Payment failed for Student@5e91993f দেখে কিছুই বোঝা যায় না।

class Student {
    private final int roll;
    private final String name;
    Student(int roll, String name) { this.roll = roll; this.name = name; }

    @Override
    public String toString() {
        return "Student[roll=" + roll + ", name=" + name + "]";
    }
}
// System.out.println(new Student(7, "Rina"));  →  Student[roll=7, name=Rina]

এখন println, string জোড়া ("Got: " + s), debugger, log — সব জায়গায় পড়ার মতো লেখা আসে। কয়েকটি ব্যবহারিক নিয়ম:

• সব গুরুত্বপূর্ণ field দেখান, যাতে log পড়ে object চেনা যায়। ClassName[field=value, …] ধরনটি প্রচলিত — record-ও ঠিক এই ধাঁচে নিজের toString বানায় (পর্ব ২৫)।
• গোপন তথ্য কখনো নয়। পাসওয়ার্ড, PIN, পুরো কার্ড নম্বর, bKash-এর OTP toString-এ রাখলে সেটা log ফাইলে চলে যাবে, আর log ফাইল প্রায়ই অনেকে পড়ে।
• toString-এর লেখাকে parse করবেন না। এটা মানুষের জন্য। অন্য প্রোগ্রামের দরকার হলে আলাদা getter বা JSON (পর্ব ৩৯) দিন, কারণ toString-এর ধরন যেকোনো দিন বদলাতে পারে।
• বিশাল collection-ভরা field হলে সংক্ষেপ করুন — যেমন orders=1520 items, পুরো তালিকা নয়।

৩ · equals — একই object, না একই মান?

পর্ব ০৭ আর ০৮-এ দেখেছেন, object-এর বেলায় == জিজ্ঞেস করে দুটি reference কি একই object দেখাচ্ছে — একে বলে reference equality. আর String-এর মান মেলাতে equals লাগে। কিন্তু String এটা পারে কারণ String class নিজে equals() override করেছে। আপনার Student যদি না করে, তাহলে Object-এর equals চলে, আর সেটা দেখতে এরকম:

public boolean equals(Object obj) {
    return (this == obj);      // java.lang.Object-এর আসল কোড, শুধু এটুকুই
}

অর্থাৎ new Student(7, "Rina").equals(new Student(7, "Rina")) হয় false — দুটি আলাদা object, রোল আর নাম এক হলেও। কখন এটাই ঠিক, আর কখন override দরকার?

equals contract — পাঁচটি শর্ত

equals override করা মানে Object-এর Javadoc-এ লেখা একটি চুক্তিতে সই করা। একে বলে equals contract. null নয় এমন যেকোনো x, y, z-এর জন্য:

শুনতে গণিতের মতো লাগলেও এগুলো সাধারণ বুদ্ধি: “সমান” শব্দটির কাছে আমরা যা আশা করি। বিপদ হলো, ভুল equals-ও দেখতে সম্পূর্ণ স্বাভাবিক লাগে।

সঠিক equals লেখার ধাপ — Money দিয়ে

import java.util.Objects;

final class Money {
    private final long poisha;        // টাকা নয়, পয়সায় — double-এর গোলমাল এড়াতে
    private final String currency;    // "BDT", "USD"
    Money(long poisha, String currency) {
        this.poisha = poisha;
        this.currency = Objects.requireNonNull(currency);
    }

    @Override
    public boolean equals(Object o) {                  // parameter Object — Money নয়!
        if (this == o) return true;                    // ১. একই object হলে সাথে সাথে হ্যাঁ
        if (!(o instanceof Money other)) return false; // ২. null বা অন্য টাইপ হলে না
        return poisha == other.poisha                  // ৩. গুরুত্বপূর্ণ প্রতিটি field মেলাও
            && currency.equals(other.currency);
    }

    @Override
    public int hashCode() { return Objects.hash(poisha, currency); }   // অংশ ৫
}

প্রতিটি লাইনের একটি কারণ আছে:

• Parameter-এর টাইপ Object. Override করতে হলে signature হুবহু Object-এর মতো হতে হয়। equals(Money m) লিখলে override নয়, একটি নতুন overload — অংশ ৪-এর সবচেয়ে বিখ্যাত ফাঁদ।
• this == o শুধু দ্রুততার জন্য: একই object হলে field মেলানোর দরকার নেই।
• instanceof Money other — পর্ব ২০-এর pattern matching দিয়ে এক লাইনে দুই কাজ: টাইপ যাচাই আর cast. আর null instanceof Money সবসময় false, তাই non-null শর্তটি বিনা খরচে পূরণ হয়।
• শুধু “গুরুত্বপূর্ণ” field. যে field পরিচয়ের অংশ, শুধু সেগুলো। Primitive field মেলান == দিয়ে (double/float হলে Double.compare), reference field মেলান equals দিয়ে।
• Class-টি final. এতে কেউ subclass বানিয়ে নতুন field যোগ করে symmetry ভাঙতে পারে না (অংশ ৪)।

কোনো field null হতে পারলে name.equals(other.name) NullPointerException দিতে পারে। তখন লিখুন Objects.equals(name, other.name) — java.util.Objects class-এর এই method দুটিই null হলে true, একটি null হলে false দেয়। নামের মিল দেখে বিভ্রান্ত হবেন না: Object হলো সবার parent class, আর Objects (শেষে s) হলো Java 7-এ আসা একটি সাহায্যকারী class, যার সব method static.

instanceof না getClass()?

অনেক পুরোনো কোড আর কিছু IDE-র তৈরি কোডে দ্বিতীয় ধাপটি এভাবে থাকে:

if (o == null || getClass() != o.getClass()) return false;
Money other = (Money) o;

getClass() চলার সময় object-এর হুবহু class দেয়। পার্থক্য দেখা যায় subclass এলে: instanceof বলে “Money বা Money-র যেকোনো subclass চলবে”, আর getClass বলে “হুবহু একই class হতে হবে”। Class final হলে দুটির ফল এক। Class final না হলে কোনটি নেবেন, সেটা একটি সত্যিকারের নকশার সিদ্ধান্ত, আর দুটিরই দাম আছে — অংশ ৪ আর ভাবনার প্রশ্ন ২-এ দেখবেন।

৪ · equals-এর দুই ফাঁদ — overload আর inheritance

ফাঁদ ১: equals(Book other) — override নয়, overload

লাইব্রেরির সফটওয়্যারে একজন লিখলেন — দেখতে একদম যুক্তিসঙ্গত:

class Book {
    private final String isbn;
    Book(String isbn) { this.isbn = isbn; }

    public boolean equals(Book other) {          // Object নয়, Book!
        return other != null && isbn.equals(other.isbn);
    }
}

a.equals(b) সরাসরি ডাকলে true আসে, তাই হাতে-কলমে পরীক্ষায় সব ঠিক মনে হয়। কিন্তু List.of(a).contains(b) আসে false! কারণ List-এর ভেতরের কোড লেখা আছে Object টাইপ দিয়ে, আর সে ডাকে equals(Object) — যেটা Book override করেনি। Book-এ এখন দুটি equals: Object থেকে পাওয়া equals(Object) (যা == করে) আর নতুন equals(Book). কোনটা চলবে, তা ঠিক হয় compile-এর সময়, ঘোষিত টাইপ দেখে (পর্ব ১২-এর overloading). Collection সবসময় প্রথমটি পায়। OpenJDK 21-এ চালিয়ে দেখা ফল: a.equals(b) true, কিন্তু Object o = b; a.equals(o) false, আর list-এর contains-ও false.

সমাধান এক শব্দের — @Override. পর্ব ১৯-এ দেখেছেন এটি compiler-কে মিলিয়ে দেখতে বলে। ওপরের method-এর মাথায় @Override বসালে javac সাথে সাথে ধরে:

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

ফাঁদ ২: subclass নতুন field যোগ করলে symmetry ভাঙে

এবার একটি বিখ্যাত উদাহরণ, যেটা Bloch-এর বইয়ে আছে। Point(x, y)-এর equals দুটি স্থানাঙ্ক মেলায়, instanceof দিয়ে। কেউ ColorPoint extends Point বানালেন, সাথে একটি color field, আর ColorPoint-এর equals তিনটি জিনিস মেলায় — x, y আর রং। দুটিই আলাদাভাবে দেখলে ঠিক মনে হয়। চুক্তির শর্তগুলো একটি একটি করে যাচাই করুন:

class Point {
  equals(o): o instanceof Point p
             && x == p.x && y == p.y
}
class ColorPoint extends Point {
  equals(o): o instanceof ColorPoint cp
             && super.equals(cp) && color.equals(cp.color)
}
p  = new Point(1, 2)
cp = new ColorPoint(1, 2, "RED")

p.equals(p)    → true  ✔
cp.equals(cp)  → true  ✔
নিজের সাথে নিজে সমান — এখানে সমস্যা নেই

p.equals(cp)   → true   cp কি Point? হ্যাঁ। x, y মেলে।
cp.equals(p)   → false  p কি ColorPoint? না।
                       ✘  symmetry ভাঙল
OpenJDK 21-এ চালিয়ে যাচাই করা

List<Point> a = [cp];   a.contains(p)  → true    (p.equals(cp))
List<Point> b = [p];    b.contains(cp) → false   (cp.equals(p))
একই দুটি বিন্দু — কে list-এ আর কে খুঁজছে,
তার ওপর উত্তর বদলায়

red  = ColorPoint(1, 2, "RED")
p    = Point(1, 2)
blue = ColorPoint(1, 2, "BLUE")

red.equals(p)     → true   (রং বাদ)
p.equals(blue)    → true
red.equals(blue)  → false   ✘  transitivity ভাঙল

field সব final → বারবার ডাকলে একই উত্তর    ✔ consistent
p.equals(null)  → false (instanceof null = false)  ✔ non-null

সমাধান: ColorPoint extends নয় —
ColorPoint-এর ভেতরে একটি Point field (composition),
অথবা Point-কে final করুন

৫ · hashCode — HashSet কীভাবে এত দ্রুত খোঁজে

দশ লাখ রেজিস্ট্রেশনের একটি তালিকায় “রোল ৭, Rina আছে কি?” — ArrayList হলে প্রতিটি উপাদানের সাথে equals ডাকতে হয়, সবচেয়ে খারাপ ক্ষেত্রে দশ লাখবার। HashSet আর HashMap এই কাজটি গড়ে প্রায় এক-দুইবার তুলনায় সারে। কৌশলটি হলো hashCode(): প্রতিটি object থেকে একটি int হিসাব করা, আর সেই int দিয়ে ঠিক করা object-টি ভেতরের টেবিলের কোন ঘরে থাকবে। সেই ঘরকে বলে bucket.

পোস্ট অফিসের কথা ভাবুন। চিঠি সাজানোর কর্মী প্রথমে পোস্ট কোড দেখে চিঠিটি সঠিক খোপে ফেলেন — ১২০৫ ধানমন্ডি, ৪০০০ চট্টগ্রাম। কোনো চিঠি খুঁজতে হলে পুরো অফিস নয়, শুধু একটি খোপ ঘাঁটলেই হয়। পোস্ট কোড হলো hashCode, খোপ হলো bucket, আর খোপের ভেতরে নাম-ঠিকানা মিলিয়ে নিশ্চিত হওয়া হলো equals. ধাপে ধাপে দেখুন:

hashCode()  → একটি int        (সংখ্যাগুলো উদাহরণ মাত্র)
int থেকে ঘর → bucket 5   (১৬টি ঘরের টেবিল)

 0 │ ·
 …
 5 │ Student(7, Rina)
 …
15 │ ·

 2 │ Student(12, Karim)
 5 │ Student(7, Rina)  →  Student(31, Sumi)
 …
Sumi-র hashCode আলাদা, কিন্তু ঘর মিলে গেল 5-এ —
একে বলে hash collision; এটা স্বাভাবিক,
একই ঘরে একটি ছোট তালিকা হয়

নতুন object, কিন্তু একই roll আর name
hashCode() → একই int  → bucket 5
শুধু bucket 5 খোঁজা হবে — বাকি ১৫টি ঘর ছোঁয়াই হবে না

bucket 5:
  Student(7, Rina)  hash মেলে?  হ্যাঁ → equals()? true
  → contains = true
Sumi পর্যন্ত যেতেই হলো না

hashCode() → অন্য int → bucket 11
bucket 11 খালি → contains = false
একবারও equals ডাকা হয়নি — "না" উত্তরও দ্রুত

hashCode-এর চুক্তি

Object-এর Javadoc তিনটি শর্ত দেয়। প্রথম দুটিই আসল:

• সমান object → সমান hashCode. বাধ্যতামূলক। এটাই সেই প্রতিশ্রুতি।
• উল্টোটা সত্য নয়: hashCode সমান হলেও object সমান না-ও হতে পারে (collision). "Aa" আর "BB"-এর hashCode হুবহু এক — চালিয়ে যাচাই করা যায়।
• একই চলার মধ্যে object না বদলালে hashCode বদলাবে না। তবে প্রোগ্রাম আবার চালালে ভিন্ন হতে পারে — তাই hashCode কখনো ফাইলে বা ডেটাবেসে সংরক্ষণ করবেন না।

একটি hashCode যা সবসময় return 42; করে, চুক্তি মানে — সমান object-এর hashCode তো সমানই! কিন্তু তখন সব object একই ঘরে, আর HashSet একটি ধীর তালিকা হয়ে যায়। ভালো hashCode আলাদা object-কে যতটা সম্ভব ছড়িয়ে দেয়। নিজে হিসাব না করে লিখুন:

@Override
public int hashCode() {
    return Objects.hash(roll, name);     // equals-এ যে field, ঠিক সেই field-ই
}

Objects.hash ভেতরে প্রতিটি field-এর hashCode নিয়ে 31 * result + h সূত্রে জোড়ে — Bloch-এর বিখ্যাত রেসিপি (ভাবনার প্রশ্ন ৩)। একমাত্র দাম: varargs বলে প্রতিবার একটি ছোট array আর primitive-এর boxing হয়। খুব গরম কোডে (কোটিবার ডাকা) হাতে 31 * Integer.hashCode(roll) + name.hashCode() লেখা হয়; সাধারণ কোডে Objects.hash-ই যথেষ্ট। মূল নিয়ম: equals-এ যে field ব্যবহার করেছেন, hashCode-এ ঠিক সেগুলোই — বেশি হলে সমান object আলাদা hash পাবে, কম হলে শুধু collision বাড়বে।

hashCode না লিখলে — হাতে-কলমে

নিচের প্রোগ্রামে দুটি class. BadStudent শুধু equals override করেছে, Student দুটোই। দুটি set-এ একই ছাত্রকে দুবার রেজিস্টার করা হচ্ছে:

import java.util.*;

class BadStudent {                          // equals আছে, hashCode নেই
    private final int roll; private final String name;
    BadStudent(int roll, String name) { this.roll = roll; this.name = name; }
    @Override public boolean equals(Object o) {
        return o instanceof BadStudent s && roll == s.roll && name.equals(s.name);
    }
}
class Student {                             // equals আর hashCode দুটোই
    private final int roll; private final String name;
    Student(int roll, String name) { this.roll = roll; this.name = name; }
    @Override public boolean equals(Object o) {
        return o instanceof Student s && roll == s.roll && name.equals(s.name);
    }
    @Override public int hashCode() { return Objects.hash(roll, name); }
}
class Main {
    public static void main(String[] args) {
        Set<BadStudent> bad = new HashSet<>();
        bad.add(new BadStudent(7, "Rina"));  bad.add(new BadStudent(7, "Rina"));
        System.out.println("bad:  size=" + bad.size() + " contains=" + bad.contains(new BadStudent(7, "Rina")));
        Set<Student> good = new HashSet<>();
        good.add(new Student(7, "Rina"));  good.add(new Student(7, "Rina"));
        System.out.println("good: size=" + good.size() + " contains=" + good.contains(new Student(7, "Rina")));
    }
}

ঠিক কোথায় ব্যাপারটা ভাঙল, BadStudent-এর দিক থেকে ধাপে ধাপে দেখুন:

1bad.add(new BadStudent(7, "Rina"));   // A2bad.add(new BadStudent(7, "Rina"));   // B3bad.contains(new BadStudent(7, "Rina")); // C4bad.size();

৬ · বদলানো যায় এমন key — HashSet-এ হারিয়ে যাওয়া object

hashCode ঠিকঠাক লিখলেও আরেকটি ফাঁদ আছে। ধরুন Student-এর name final নয়, একটি setName আছে। Rina-কে set-এ রাখার পর তার নাম সংশোধন করে করা হলো “Rina Akter”:

Set<Student> set = new HashSet<>();
Student s = new Student(7, "Rina");     // name এবার mutable, hashCode = Objects.hash(roll, name)
set.add(s);                              // পুরোনো নামের hash দিয়ে একটি ঘরে বসল
s.setName("Rina Akter");                 // hash বদলে গেল, কিন্তু object আগের ঘরেই রইল
System.out.println(set.contains(s));     // false — একই object, তবু "নেই"!
set.add(s);
System.out.println(set.size());          // 2 — একই object দুবার

OpenJDK 21-এ চালিয়ে দেখা ফল: false, তারপর 2. object-টি এখনো set-এর ভেতরেই আছে, কিন্তু পুরোনো নামের ঘরে। নতুন নামের hash অন্য ঘর দেখায়, সেখানে কেউ নেই। আর আবার add করলে একই object দ্বিতীয় ঘরে ঢোকে। remove(s)-ও ব্যর্থ হয় — object-টি কার্যত set-এর ভেতরে আটকে গেল, একটি ছোট memory leak.

এখান থেকে equals-এর জন্য field বাছাইয়ের একটি সাধারণ নিয়মও বেরিয়ে আসে। লাইব্রেরির একটি Book-এ আছে isbn, title, copiesAvailable আর lastBorrowedAt. শেষ দুটি প্রতিদিন বদলায় — বই ধার দেওয়া হলেই। এগুলো বইয়ের পরিচয় নয়, অবস্থা। এগুলো equals-এ রাখলে একই বই সকালে আর বিকেলে “আলাদা” হয়ে যাবে। আর যে field অন্য field থেকে হিসাব করা যায় (যেমন totalPrice = price * qty), সেটাও রাখার দরকার নেই — বাড়তি কাজ, আর অমিলের ঝুঁকি। এখানে পরিচয় শুধু isbn.

৭ · Comparable আর compareTo — স্বাভাবিক ক্রম

equals বলে দুটি জিনিস সমান কি না। কিন্তু অনলাইন দোকানে পণ্য “সস্তা থেকে দামি” সাজাতে জানতে হয় কোনটি আগে। Java-তে একটি class নিজের এই natural ordering ঘোষণা করে Comparable<T> interface implement করে। এর একটিই method — compareTo:

খেয়াল করুন, শুধু চিহ্ন গুরুত্বপূর্ণ — −১ আর −৫০০-এর মানে একই। এরও চুক্তি আছে, equals-এর মতোই: উল্টালে চিহ্ন উল্টাবে (a < b হলে b > a), transitive (a < b আর b < c হলে a < c), আর শূন্য পাওয়া দুটি object অন্য সবার সাথে একইভাবে তুলনীয়। আর একটি জোরালো সুপারিশ: compareTo শূন্য দিলে equals-ও true দেওয়া উচিত — একে বলে “consistent with equals”.

কেন? HashSet সমান কি না দেখে equals দিয়ে, কিন্তু TreeSet দেখে compareTo দিয়ে। দুটি অমিল হলে একই ডেটা দুই set-এ আলাদা আচরণ করে। JDK-র নিজের উদাহরণ BigDecimal: 4.0 আর 4.00-এর compareTo শূন্য (সংখ্যা হিসেবে সমান), কিন্তু equals false (scale আলাদা)। ফলে দুটিকে HashSet-এ রাখলে size 2, TreeSet-এ রাখলে size 1 — OpenJDK 21-এ চালিয়ে যাচাই করা। Comparable-এর Javadoc নিজেই BigDecimal-কে এই ব্যতিক্রমের উদাহরণ হিসেবে দেখায়।

দামের ক্রমে Product — আর বিয়োগের bug

import java.util.*;

class Product implements Comparable<Product> {
    private final String name;
    private final int price;                       // টাকায়
    Product(String name, int price) { this.name = name; this.price = price; }
    @Override public int compareTo(Product other) {
        return Integer.compare(price, other.price);  // বিয়োগ নয়
    }
    @Override public String toString() { return name + "=" + price; }
}
class Main {
    public static void main(String[] args) {
        Product[] cart = { new Product("Bag", 1500), new Product("Pen", 20),
                           new Product("Book", 350), new Product("Lamp", 900) };
        Arrays.sort(cart);                            // compareTo দিয়ে সাজায়
        System.out.println(Arrays.toString(cart));

        int a = -2_000_000_000, b = 2_000_000_000;    // a আসলে b-এর চেয়ে ছোট
        System.out.println("a - b = " + (a - b));
        System.out.println("Integer.compare(a, b) = " + Integer.compare(a, b));
    }
}

“দাম তো কখনো ২০০ কোটি হবে না” — সত্যি, Product-এর দাম হয়তো কখনো overflow করবে না। কিন্তু একই অভ্যাস একদিন ব্যালান্স, timestamp, ঋণাত্মক তাপমাত্রা বা hash মান তুলনায় চলে যায়। সবচেয়ে চরম ক্ষেত্রটি ধাপে ধাপে দেখুন:

1int a = Integer.MIN_VALUE;  // -21474836482int b = 1;3int bad = a - b;            // compareTo-র ভুল ধরন4int good = Integer.compare(a, b);

Comparable না থাকলে, আর একাধিক ক্রম দরকার হলে

যে class Comparable নয়, তার array Arrays.sort-এ দিলে compile হয়ে যায় (method-টি Object[] নেয়), কিন্তু চলার সময় ভেঙে পড়ে:

Exception in thread "main" java.lang.ClassCastException: class Book cannot be cast to class java.lang.Comparable (Book is in unnamed module of loader 'app'; java.lang.Comparable is in module java.base of loader 'bootstrap')

আর Comparable implement করে compareTo লিখতে ভুলে গেলে javac ধরে:

Main.java:1: error: Product is not abstract and does not override abstract method compareTo(Product) in Comparable
class Product implements Comparable<Product> {
^
1 error

একটি class-এর natural ordering একটিই হয় — Product-এর ক্ষেত্রে দাম। কিন্তু একই পণ্য কখনো নামের ক্রমে, কখনো রেটিং-এর ক্রমে সাজাতে হয়। তার জন্য class-এর বাইরে থেকে নিয়ম দেওয়া হয় Comparator দিয়ে, যেমন Arrays.sort(cart, Comparator.comparing(Product::name)) — পর্ব ৩৩-এর পুরো বিষয়। আপাতত মনে রাখুন: Comparable = “আমি নিজে কীভাবে সাজি”, Comparator = “বাইরে থেকে বলা অন্য একটি ক্রম”।

৮ · নিজে না লিখে — IDE, record, Lombok; আর clone কেন নয়

এত নিয়ম জেনে মনে হতে পারে প্রতিটি class-এ ৩০ লাইন হাতে লিখতে হবে। বাস্তবে পেশাদাররা প্রায় কখনো হাতে লেখেন না। তিনটি উপায় আছে, পুরোনো থেকে নতুন:

নিয়ম না জানলে টুল-ও বিপদ: IDE-তে সব field-এ টিক দিলে copiesAvailable-এর মতো বদলানো field-ও equals-এ ঢুকবে। টুল কোড লেখে, কোন field পরিচয় — সেই সিদ্ধান্ত আপনার।

clone() — কেন এড়ানো হয়

Object-এর clone() দেখে মনে হয় কপি বানানোর সহজ পথ। কিন্তু এর নকশা অদ্ভুত: Cloneable interface-এ কোনো method নেই, শুধু একটি “অনুমতির চিহ্ন”; না থাকলে clone চলার সময় CloneNotSupportedException দেয়। clone constructor না ডেকেই object বানায়, তাই final field নতুন করে বসানো যায় না। আর ডিফল্টে shallow copy করে — ভেতরের list বা array দুই কপির মধ্যে ভাগাভাগি থাকে। Bloch নিজে বলেছেন Cloneable “broken”. পর্ব ১৬-এ দেখা copy constructor (new Student(other)) বা একটি static factory (Student.copyOf(other)) প্রায় সবসময় ভালো: স্পষ্ট, final-বান্ধব, আর আপনি নিজে ঠিক করেন কোনটা গভীর কপি হবে। (আর finalize()? সেটা Java 9 থেকে deprecated — ব্যবহার করবেন না; resource বন্ধ করতে try-with-resources, পর্ব ২৯।)

৯ · AI-এর যুগে — চুক্তি যাচাই করা আপনার কাজ

AI-কে “একটি Student class লিখে দাও” বললে সাধারণত সুন্দর দেখতে কোড আসে। কিন্তু এই পর্বের bug-গুলো ঠিক সেই ধরনের যা compile হয়, চলে, আর ছোট টেস্টে ধরা পড়ে না — তাই AI-এর আউটপুটে এগুলো প্রায়ই টিকে থাকে। AI শিখেছে লাখো পুরোনো টিউটোরিয়াল থেকে, যার অনেকগুলোতে বিয়োগ দিয়ে compareTo বা hashCode ছাড়া equals আছে।

AI-এর লেখা equals/hashCode হাতে পেলে — যাচাইয়ের চেকলিস্ট

• equals আর hashCode দুটোই আছে, আর দুটিতে হুবহু একই field
• equals-এর parameter Object, আর চারটি method-এর প্রতিটিতে @Override আছে
• equals-এ শুধু পরিচয়ের field — বদলানো অবস্থা (stock, lastLogin) বা হিসাব-করা field নেই
• HashSet-এ দুটি সমান object রেখে size 1 আর contains true পেয়েছি
• compareTo-তে কোনো বিয়োগ নেই; Integer.MIN_VALUE বা খুব বড় মান দিয়ে sort করে দেখেছি
• Class final বা record; না হলে subclass-এ নতুন field যোগ করলে symmetry ভাঙে কি না ভেবেছি
• toString-এ গোপন তথ্য নেই, আর কেউ toString-এর লেখা parse করছে না