record — ডেটার জন্য ছোট class

১ · যে class শুধু ডেটা বহন করে — আর boilerplate-এর বোঝা

পর্ব ১৫ থেকে আপনি যত class লিখেছেন, সেগুলোকে দুই ভাগে ফেলা যায়। এক ভাগের class-এর ভেতরে আসল কাজ আছে — Account টাকা জমা নেয়, নিয়ম পাহারা দেয়, ব্যালান্স বদলায়। আরেক ভাগের class কোনো কাজই করে না; শুধু কয়েকটি মান একসাথে বেঁধে এক জায়গা থেকে আরেক জায়গায় নিয়ে যায়। একটি bKash লেনদেনের রেকর্ড (আইডি, টাকার অঙ্ক, ধরন), মানচিত্রের একটি বিন্দু (অক্ষাংশ, দ্রাঘিমাংশ), একজন পরীক্ষার্থীর ফল (রোল, GPA), কোনো API থেকে আসা একটি উত্তর। এদের বলে data carrier — ডেটার বাহক।

সমস্যা হলো, Java 16-এর আগে এমন একটি সাধারণ রসিদ লিখতেও অনেক কোড লাগত। তিনটি field-এর একটি লেনদেন class “ঠিকভাবে” লিখলে দেখতে এরকম:

import java.util.Objects;

public final class Transaction {
    private final String id;
    private final long amount;
    private final String type;

    public Transaction(String id, long amount, String type) {
        this.id = id;
        this.amount = amount;
        this.type = type;
    }

    public String getId()   { return id; }
    public long getAmount() { return amount; }
    public String getType() { return type; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Transaction)) return false;
        Transaction other = (Transaction) o;
        return amount == other.amount
                && Objects.equals(id, other.id)
                && Objects.equals(type, other.type);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, amount, type);
    }

    @Override
    public String toString() {
        return "Transaction[id=" + id + ", amount=" + amount
                + ", type=" + type + "]";
    }
}

প্রায় ৪০ লাইন, অথচ এর মধ্যে নতুন তথ্য মাত্র একটি: “একটি লেনদেনে আছে id, amount আর type”. বাকি সব হলো boilerplate — একই ছাঁচে বারবার লেখা কোড। আর boilerplate শুধু ক্লান্তিকর নয়, বিপজ্জনকও। পর্ব ২৩-এ দেখেছেন equals আর hashCode-এর চুক্তি: দুটি object equals হলে তাদের hashCode সমান হতেই হবে। এখন কেউ class-এ চতুর্থ field fee যোগ করলেন, equals-এ যোগ করলেন, hashCode-এ ভুলে গেলেন — কোড compile হবে, কিন্তু HashMap-এ অদ্ভুত bug আসবে। ৪০ লাইনের ভেতরে এই ভুল চোখে পড়ে না।

Java 16-এ একই জিনিস লেখা যায় এক লাইনে:

record Transaction(String id, long amount, String type) {}

এটাই record. বন্ধনীর ভেতরের তিনটি অংশকে বলে record component. এই এক লাইনের ভেতরে ওপরের ৪০ লাইনের প্রায় সবকিছু আছে — আর যেহেতু compiler লেখে, equals আর hashCode কখনো একে অপরের সাথে অমিল হয় না। নতুন component যোগ করলে সব method নিজে থেকেই হালনাগাদ হয়।

২ · এক লাইনের ভেতরে কী আছে — compiler যা তৈরি করে

record Transaction(String id, long amount, String type) {} লিখলে javac আসলে একটি পূর্ণাঙ্গ class তৈরি করে। Reflection দিয়ে compile হওয়া class-টির ভেতরটা দেখলে (OpenJDK 21-এ যাচাই করা) যা পাওয়া যায়, ধাপে ধাপে দেখুন:

record Transaction(String id, long amount, String type) {}

একটি নাম + তিনটি component (নাম ও টাইপ)
শরীর {} খালি — তবু নিচের সব তৈরি হবে

final class Transaction extends java.lang.Record {
    private final String id;
    private final long   amount;
    private final String type;
প্রতিটি component থেকে একটি private final field
class নিজে final — কেউ extends করতে পারবে না

    Transaction(String id, long amount, String type) {
        this.id = id;
        this.amount = amount;
        this.type = type;
    }
সব component, একই ক্রমে — এর নাম canonical constructor
access record-এর মতোই (এখানে package-private)

    public String id()     { return id; }
    public long   amount() { return amount; }
    public String type()   { return type; }
নাম component-এর নামেই — getAmount() নয়
setter একটিও নেই

    public final boolean equals(Object o)  // সব component তুলনা
    public final int hashCode()            // সব component থেকে
    public final String toString()         // নাম=মান তালিকা
}
Transaction[id=TX101, amount=500, type=SEND]   ← toString

getAmount() নয়, amount() — JavaBeans-এর সাথে পার্থক্য

পর্ব ১৭-এ getter-এর নাম রেখেছিলেন getBalance() — এটা JavaBeans রীতি। record এই রীতি মানে না; accessor-এর নাম component-এর নামেই। পুরোনো অভ্যাসে t.getAmount() লিখলে javac বলে:

Main.java:5: error: cannot find symbol
        System.out.println(t.getAmount());
                            ^
  symbol:   method getAmount()
  location: variable t of type Transaction
1 error

কেন এই সিদ্ধান্ত? কারণ record-এর দর্শন হলো “component আর accessor একই জিনিস”। হেডারে যা লিখেছেন, ঠিক সেই নামেই মান ফেরত পাবেন — কোনো নামবদল নেই। এর একটি ব্যবহারিক মূল্যও আছে: অংশ ৮-এর record pattern-এ Transaction(String id, long amount, String type) লিখে যে নামে ভাঙা হয়, constructor-এ সেই নামে বানানো হয় আর accessor-ও সেই নামে পড়ে। তিন জায়গায় এক নাম।

toString নিয়ে একটি ছোট কথা। পর্ব ২৩-এ সতর্ক করা হয়েছিল, Object-এর ডিফল্ট toString (ClassName@hash) প্রতিবার চালালে আলাদা হতে পারে, তাই সেটা ছাপা ঠিক নয়। record-এর toString সে রকম নয় — এটা শুধু component-এর মান দিয়ে তৈরি, তাই একই মান মানে একই লেখা। লগে আর ডিবাগে নিশ্চিন্তে ছাপতে পারেন। তবে Record-এর Javadoc বলে এর সঠিক ফরম্যাট implementation-এর বিষয় এবং ভবিষ্যতে বদলাতে পারে; তাই toString-এর লেখা parse করে ডেটা বের করার কোড লিখবেন না — ডেটা চাইলে accessor ডাকুন।

৩ · compact constructor — যাচাই আর মান ঠিক করা

record বানানো সহজ, কিন্তু একটি প্রশ্ন থেকে যায়: ভুল মান ঢুকলে কী হবে? bKash-এ ঋণাত্মক টাকার লেনদেন হয় না। মানচিত্রে অক্ষাংশ −৯০ থেকে ৯০-এর বাইরে যেতে পারে না। একটি পরিসরের শুরু তার শেষের চেয়ে বড় হতে পারে না। পর্ব ১৬-এ শিখেছেন, এমন নিয়ম (invariant) পাহারা দেওয়ার জায়গা constructor. record-এ এর জন্য আছে একটি বিশেষ ছোট রূপ — compact constructor:

record Location(double lat, double lon) {
    Location {                                       // বন্ধনী নেই, parameter তালিকা নেই
        if (lat < -90 || lat > 90)
            throw new IllegalArgumentException("lat out of range: " + lat);
        if (lon < -180 || lon > 180)
            throw new IllegalArgumentException("lon out of range: " + lon);
    }                                                // এখানে this.lat = lat; ... নিজে থেকে বসে
}

খেয়াল করুন তিনটি জিনিস। এক, নামের পরে কোনো বন্ধনী নেই — parameter তালিকা হেডার থেকেই জানা। দুই, ভেতরে lat আর lon হলো parameter, field নয়। তিন, শরীরের শেষে compiler নিজে this.lat = lat; this.lon = lon; বসায়। ফলে আপনার কোডে শুধু নিয়মটুকু থাকে, বাকি সব নিয়মমাফিক।

Compact constructor শুধু যাচাই নয়, মান ঠিক করতেও (normalization) পারে। parameter-এ নতুন মান বসালে, শেষে field-এ সেই নতুন মানই যায়। লেনদেনের ধরন কেউ “send”, কেউ “SEND” লিখলে সবগুলোকে বড় হাতের অক্ষরে আনা যায়। পুরো ঘটনাটি ধাপে ধাপে দেখুন:

1record Transaction(String id, long amount, String type) {2  Transaction {3    if (amount <= 0)4      throw new IllegalArgumentException(...);5    type = type.toUpperCase(Locale.ROOT);6  }  // লুকানো: this.id = id; this.amount = amount; this.type = type;7}8new Transaction("TX101", 500, "send");9new Transaction("TX102", -50, "cash-out");

এবার চালিয়ে দেখুন — record বানানো, accessor, equals, HashSet আর যাচাই, সব একসাথে:

import java.util.*;

record Transaction(String id, long amount, String type) {
    Transaction {                                   // compact constructor
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive: " + amount);
        type = type.toUpperCase(Locale.ROOT);       // normalization
    }
}

class Main {
    public static void main(String[] args) {
        var t1 = new Transaction("TX101", 500, "send");
        var t2 = new Transaction("TX101", 500, "SEND");
        System.out.println(t1);
        System.out.println(t1.amount() + " " + t1.type());
        System.out.println(t1.equals(t2) + " " + (t1 == t2));
        Set<Transaction> seen = new HashSet<>(List.of(t1));
        System.out.println(seen.contains(t2));
        try {
            new Transaction("TX102", -50, "cash-out");
        } catch (IllegalArgumentException e) {
            System.out.println("rejected: " + e.getMessage());
        }
    }
}

compact constructor-এ field ছোঁয়া যায় না

নতুনদের একটি সাধারণ ভুল: compact constructor-এর ভেতরে পুরোনো অভ্যাসে this.start = start; লেখা। Field বসানোর কাজ compiler নিজে করবে, তাই আপনার হাতে সেটা নিষিদ্ধ:

record Range(int start, int end) {
    Range {
        this.start = start;
    }
}

Main.java:3: error: cannot assign a value to final variable start
        this.start = start;
            ^
1 error

সমাধান সহজ: লাইনটি মুছে দিন। মান বদলাতে চাইলে parameter-এ বসান (start = Math.max(0, start);), field-এ নয়। আর যদি সত্যিই সব field নিজে বসাতে চান, তাহলে compact রূপের বদলে পুরো canonical constructor লিখুন — Range(int start, int end) { this.start = start; this.end = end; } — তখন সব field নিজেকেই বসাতে হবে। প্রায় সব ক্ষেত্রে compact রূপই পরিষ্কার।

৪ · আরও constructor, method আর static factory

record-এর শরীর খালি রাখতে হবে এমন কোনো কথা নেই। সাধারণ class-এর মতো এখানে method, static field, static method, এমনকি অতিরিক্ত constructor-ও লেখা যায়। একটি পরিসর (Range) দিয়ে সব দেখা যাক:

record Range(int start, int end) {
    static final Range EMPTY = new Range(0, 0);          // static field — চলে

    Range {                                              // compact: নিয়ম পাহারা
        if (start > end)
            throw new IllegalArgumentException("start > end: " + start + " > " + end);
    }
    Range(int end) { this(0, end); }                     // অতিরিক্ত constructor → canonical-কে ডাকে

    int length() { return end - start; }                 // সাধারণ method
    boolean contains(int x) { return start <= x && x < end; }

    static Range of(int a, int b) {                      // static factory: ক্রম নিজে ঠিক করে
        return new Range(Math.min(a, b), Math.max(a, b));
    }
}

এই record-এ new Range(5) দেয় Range[start=0, end=5], যার length() হলো 5; আর Range.of(9, 3) দেয় Range[start=3, end=9] (OpenJDK 21-এ চালিয়ে যাচাই করা)। দুটি নিয়ম লক্ষ করুন।

এক, অতিরিক্ত constructor-কে প্রথম লাইনেই অন্য constructor ডাকতে হবে। Range(int end) নিজে field বসাতে পারে না; সে this(0, end) দিয়ে শেষ পর্যন্ত canonical constructor-এ যায়। এতে নিশ্চিত হয় যে compact constructor-এর যাচাই কখনো বাদ পড়ে না — record-এর প্রতিটি object একই দরজা দিয়ে ঢোকে। এই নিয়ম ভাঙলে:

record Range(int start, int end) {
    Range(int end) {
        System.out.println("x");
    }
}

Main.java:2: error: constructor is not canonical, so its first statement must invoke another constructor of class Range
    Range(int end) {
    ^
1 error

দুই, static factory method নাম দিয়ে উদ্দেশ্য বোঝায়। Range.of(9, 3) ভুল ক্রমে দেওয়া মান নিজে সাজিয়ে নেয়, আর new Range(9, 3) সরাসরি exception দেয়। দুটোই রাখা যায় — কঠোর দরজা আর সুবিধাজনক দরজা। JDK-র List.of, Map.of একই ধারণা।

instance field নিষেধ — state শুধু হেডারে

record-এর শরীরে static field চলে, কিন্তু নতুন instance field চলে না। ধরুন কেউ লেনদেনে “কতবার পাঠানোর চেষ্টা হলো” রাখতে চাইলেন:

record Transaction(String id, long amount, String type) {
    private int retries;
}

Main.java:2: error: field declaration must be static
    private int retries;
                ^
  (consider replacing field with record component)
1 error

javac নিজেই পরামর্শ দিচ্ছে: field-টিকে component বানান। কারণ record-এর প্রতিশ্রুতি — “সব state হেডারে ঘোষিত”। হেডারের বাইরে লুকানো field থাকলে equals, hashCode আর toString সেটা দেখত না, আর “দুটি record-এর component সমান মানে record সমান” কথাটি মিথ্যা হয়ে যেত। একই কারণে record-এর method field বদলাতে পারে না:

record Transaction(String id, long amount, String type) {
    void refund() { amount = 0; }
}

Main.java:2: error: cannot assign a value to final variable amount
    void refund() { amount = 0; }
                    ^
1 error

তাহলে “বদলানো” কীভাবে হয়? নতুন record বানিয়ে। Transaction refunded() { return new Transaction(id, 0, "REFUND"); } — পুরোনোটা যেমন ছিল তেমনই থাকে, নতুন মানের জন্য নতুন object. পর্ব ০৮-এর String-এর মতো: toUpperCase() আগেরটা বদলায় না, নতুন String দেয়। এভাবে একটি component বদলে নতুন কপি দেওয়া method-কে প্রচলিত ভাষায় “wither” বলে (withAmount(...))। Java 21-এ record নিজে থেকে wither বানায় না, প্রয়োজন হলে হাতে লিখতে হয়। ভবিষ্যতের জন্য JEP 468 (“derived record creation”) নামে একটি প্রস্তাব আছে, যা with দিয়ে কপি বানানোর syntax আনতে চায়; এই কোর্সের Java 21-এ সেটা নেই।

৫ · record-এর সীমা — final, extends নেই, interface আছে

অংশ ২-এর stepper-এ দেখেছেন, record নিজে থেকে final আর তার superclass java.lang.Record. এর দুটি ফল।

কেউ record extends করতে পারে না। পর্ব ১৯-এর final class-এর মতো:

record Point(int x, int y) {}
class Point3D extends Point { }

Main.java:2: error: cannot inherit from final Point
class Point3D extends Point { }
                      ^
Main.java:2: error: constructor Point in record Point cannot be applied to given types;
class Point3D extends Point { }
^
  required: int,int
  found:    no arguments
  reason: actual and formal argument lists differ in length
2 errors

প্রথম error-টিই আসল কথা: Point final, তাই তার উত্তরসূরি হয় না। দ্বিতীয়টি পর্ব ১৯-এর পরিচিত লুকানো super() — Point3D-এর default constructor parameter ছাড়া Point-এর constructor খোঁজে, অথচ record-এর canonical constructor চায় দুটি int. প্রথমটি সারানোর কোনো উপায় নেই, তাই দ্বিতীয়টি নিয়ে মাথা ঘামানোর দরকারও নেই।

record নিজেও কিছু extends করতে পারে না — তার parent ইতিমধ্যে ঠিক করা (Record), আর Java-তে parent একটিই। হেডারের পরে extends লিখলে:

class Base {}
record Point(int x, int y) extends Base {}

Main.java:2: error: '{' expected
record Point(int x, int y) extends Base {}
                          ^
1 error

কেন এত কড়াকড়ি? কারণ subclass এলে record-এর প্রতিশ্রুতি ভাঙে। Point3D একটি z যোগ করলে Point(1, 2) আর Point3D(1, 2, 9) কি সমান? Point-এর equals বলবে হ্যাঁ, Point3D-এরটা বলবে না — equals-এর symmetry ভেঙে যায়, যা পর্ব ২৩-এর সবচেয়ে কঠিন সমস্যাগুলোর একটি। record এই প্রশ্ন পুরোপুরি বন্ধ করে দিয়েছে।

কিন্তু interface implement করা যায়, যত খুশি। এতে record-কে সাজানো যায়, অন্য টাইপের অংশ বানানো যায়। একটি পরীক্ষার ফলকে GPA অনুযায়ী সাজাতে:

record ExamResult(int roll, double gpa) implements Comparable<ExamResult> {
    public int compareTo(ExamResult o) {
        int byGpa = Double.compare(o.gpa, gpa);          // বেশি GPA আগে
        return byGpa != 0 ? byGpa : Integer.compare(roll, o.roll);
    }
}

লক্ষ করুন, record-এর ভেতরে o.gpa লিখে সরাসরি field পড়া যায় (একই class), আর বাইরে থেকে o.gpa(). পর্ব ২৬-এ দেখবেন record আর sealed interface একসাথে কী শক্তিশালী — sealed interface Shape permits Circle, Square, যেখানে Circle আর Square দুটিই record.

৬ · shallow immutability — ভেতরের List আর array-এর ফাঁদ

record-এর field final, তাই একবার বসলে আর বদলায় না। কিন্তু পর্ব ১৮-এ দেখেছেন, final reference মানে reference-টা বদলায় না — reference যে object-কে দেখায়, তার ভেতরটা বদলাতে পারে। record-এর ক্ষেত্রেও একই কথা। একে বলে shallow immutability — অগভীর অপরিবর্তনীয়তা। component যদি String, int বা অন্য record হয়, সমস্যা নেই; কিন্তু List বা array হলে record আসলে immutable নয়।

একটি ব্যাচের রোল নম্বরের তালিকা রাখা record ভাবুন। যে কোড record বানিয়েছে, তার হাতে এখনো মূল ArrayList-এর reference আছে। সে তালিকায় কিছু যোগ করলে কী হয়? ধাপে ধাপে দেখুন:

list ─────────────┐
                  ▼
           ┌──────────────┐
b.rolls ──▶│ [101, 102]   │   ArrayList (heap)
           └──────────────┘
record-এর field আর বাইরের list — একই object-কে দেখায়

list ─────────────┐
                  ▼
           ┌───────────────────┐
b.rolls ──▶│ [101, 102, 999]  │
           └───────────────────┘
b.rolls() → [101, 102, 999]
record-এর field বদলায়নি, কিন্তু তার দেখানো তালিকা বদলেছে

list ──────▶ ┌───────────────────┐
             │ [101, 102, 999]   │   বাইরের ArrayList
             └───────────────────┘
             ┌───────────────────┐
s.rolls ───▶ │ [101, 102]        │   নতুন, unmodifiable কপি
             └───────────────────┘
কপি নেওয়া হয়েছিল record বানানোর মুহূর্তে — পরে list বদলালেও এটা অটল

s.rolls().add(5)
   ✘ UnsupportedOperationException
accessor যে তালিকা ফেরত দেয়, সেটা দিয়েও ভেতরটা বদলানো যায় না
ঢোকার পথ আর বের হওয়ার পথ — দুটোই বন্ধ

চালিয়ে মিলিয়ে নিন — সাথে অংশ ৭-এর একটি local record-ও আছে:

import java.util.*;

record LeakyBatch(String name, List<Integer> rolls) {}
record Batch(String name, List<Integer> rolls) {
    Batch { rolls = List.copyOf(rolls); }           // defensive copy
}

class Main {
    public static void main(String[] args) {
        var list = new ArrayList<>(List.of(101, 102));
        var leaky = new LeakyBatch("A", list);
        var safe = new Batch("A", list);
        list.add(999);                              // বাইরে থেকে বদল
        System.out.println(leaky.rolls() + " " + safe.rolls());
        try { safe.rolls().add(5); }
        catch (UnsupportedOperationException e) { System.out.println("safe list cannot change"); }

        record Result(int roll, double gpa) {}      // local record
        var results = new ArrayList<>(List.of(new Result(103, 4.5), new Result(101, 5.0), new Result(102, 4.5)));
        results.sort(Comparator.comparingDouble(Result::gpa).reversed().thenComparingInt(Result::roll));
        results.forEach(System.out::println);
    }
}

array-এর দুটি সমস্যা

array component আরও ঝামেলার। প্রথমত, array-এর জন্য List.copyOf-এর মতো unmodifiable রূপ নেই, তাই ঢোকার সময় marks = marks.clone(); আর accessor-কেও নিজে লিখে কপি ফেরত দিতে হয় — public int[] marks() { return marks.clone(); }. দ্বিতীয়ত, record-এর equals প্রতিটি component তুলনা করে সেই component-এর নিজের equals দিয়ে, আর array-এর equals হলো reference তুলনা (পর্ব ১৩)। ফলে record Scores(int[] marks)-এ একই নম্বরের দুটি আলাদা array দিলে দুটি record সমান নয় — OpenJDK 21-এ চালালে false আসে। তাই সাধারণ নিয়ম: record-এ array নয়, List রাখুন, আর compact constructor-এ List.copyOf.

৭ · Map-এর key, Set আর local record

record-এর সবচেয়ে বড় সুবিধাগুলোর একটি হলো HashMap-এর key বা HashSet-এর উপাদান হিসেবে এটা প্রথম দিন থেকেই ঠিকঠাক কাজ করে। কারণ equals আর hashCode দুটিই component থেকে তৈরি, আর দুটি একে অপরের সাথে মিলে থাকে। হাতে লেখা class-এ equals বা hashCode ভুলে গেলে কী হয়, আর record-এ কী হয় — পাশাপাশি দেখুন:

set.add(new PointC(1, 2));

বালতি ক:  [ PointC(1,2) #১ ]
hashCode আসে Object থেকে — object-এর পরিচয় থেকে, মান থেকে নয়

নতুন object #২ → অন্য hashCode → (প্রায় সবসময়) অন্য বালতি
বালতি খ:  [ ]      → খুঁজে পেল না
একই বালতিতে পড়লেও equals = reference তুলনা → #১ ≠ #২
ফল: false   — একই মান, তবু “নেই”

hashCode = f(x=1, y=2)   — শুধু component থেকে
বালতি গ:  [ Point[x=1, y=2] ]
new Point(1, 2) আবার বানালে → একই hashCode → একই বালতি গ

বালতি গ-তে গিয়ে equals:
  x: 1 == 1 ✔   y: 2 == 2 ✔
ফল: true
map.get(new Point(1, 2)) → "shop"   (একই নিয়মে)

local record — একটি method-এর ভেতরের সাময়িক ডেটা

অনেক সময় একটি method-এর ভেতরেই কিছু মান সাময়িকভাবে জোড়া বাঁধা দরকার হয় — যেমন রোল আর GPA একসাথে সাজাতে। এর জন্য আলাদা ফাইলে class বানানো বাড়াবাড়ি, আবার দুটি আলাদা array রেখে একসাথে সাজানো ঝামেলার। Java 16 থেকে method-এর ভেতরেই record ঘোষণা করা যায় — local record. অংশ ৬-এর runnable কোডে record Result(int roll, double gpa) {} ঠিক এটাই: main-এর ভেতরে জন্ম, main-এর বাইরে কেউ জানে না। local record নিজে থেকে static, তাই বাইরের method-এর local variable ব্যবহার করতে পারে না — এটা শুধু ডেটার একটি ছাঁচ, কোনো লুকানো সংযোগ নেই। Stream-এর মাঝখানের ধাপে (পর্ব ৩৫) এর ব্যবহার সবচেয়ে বেশি।

৮ · কখন record নয় — Lombok, class, entity আর record pattern

record দেখে প্রথমে মনে হয়, “সব class-ই তো record বানিয়ে ফেলি!” না। record-এর প্রতিশ্রুতি — “মানই পরিচয়, আর মান কখনো বদলায় না” — যেখানে খাটে না, সেখানে record ভুল হাতিয়ার।

পার্থক্যটা পরিচয় (identity) নিয়ে। দুটি Location(23.81, 90.41) সব দিক থেকে একই বিন্দু — আলাদা করার কোনো কারণ নেই। কিন্তু একই নামে, একই ব্যালান্সের দুজন গ্রাহকের দুটি account আলাদা account; একটিতে টাকা জমা হলে অন্যটিতে হয় না। account-এর পরিচয় তার মানের বাইরে (account নম্বর, জীবনকাল), আর তার মান সময়ের সাথে বদলায়। এমন জিনিস record দিয়ে লিখলে প্রতিটি জমার পর নতুন object বানাতে হবে, আর পুরোনো reference যারা ধরে আছে তারা পুরোনো ব্যালান্স দেখবে।

record বনাম Lombok @Value বনাম হাতে লেখা class

record আসার আগে Java জগতে boilerplate কমানোর জনপ্রিয় উপায় ছিল Lombok — একটি তৃতীয় পক্ষের লাইব্রেরি, যার @Value annotation একটি class-কে final, field-গুলোকে private final বানায়, আর getter, equals, hashCode, toString তৈরি করে।

নতুন কোডে সরল ডেটা বাহকের জন্য record-ই প্রথম পছন্দ — বাইরের নির্ভরতা নেই, আর ভাষা নিজে এর অর্থ জানে। Lombok এখনো কাজে লাগে যেখানে JavaBeans নামের getter বাধ্যতামূলক (কিছু পুরোনো framework), বা বদলযোগ্য class-এ boilerplate কমাতে হয়।

record pattern — একটি ঝলক

record স্বচ্ছ — বাইরে থেকে জানা যায় এর ভেতরে কী কী আছে। এই স্বচ্ছতা কাজে লাগিয়ে Java 21-এ স্থায়ী হয়েছে record pattern: একটি object record কি না যাচাই আর তার component বের করা, এক ধাপে।

Object o = new Point(3, 4);
if (o instanceof Point(int x, int y)) {     // Point হলে x আর y সরাসরি পাওয়া যায়
    System.out.println(x + y);              // 7
}

এখানে cast নেই, p.x()-এর ডাক নেই — pattern matching এক ধাপে ভেঙে দিয়েছে (OpenJDK 21-এ চালিয়ে 7 পাওয়া গেছে)। switch-এর ভেতরে nested record pattern আর sealed interface মিলিয়ে এর আসল শক্তি দেখবেন পরের পর্বে, পর্ব ২৬-এ।

Jackson, Spring আর record

বাস্তব প্রজেক্টে record-এর সবচেয়ে বড় ব্যবহার API-র ডেটা আনা-নেওয়ায় (DTO). JSON-কে Java object-এ রূপ দেওয়ার জনপ্রিয় লাইব্রেরি Jackson-এর আধুনিক সংস্করণ (2.12 থেকে) record সরাসরি বোঝে — component-এর নাম দেখে JSON-এর key মেলায় আর canonical constructor দিয়ে object বানায়। Spring Boot-এর আধুনিক সংস্করণেও REST controller-এর request/response আর configuration properties-এ record ব্যবহার করা যায়। এগুলো JDK-র অংশ নয়, তাই এখানে চালানো যাবে না; পর্ব ৩৯ আর ৫১-এ হাতে-কলমে দেখবেন। একটি কথা মনে রাখুন: যে framework-কে খালি constructor আর setter দিয়ে object বানাতে হয় (পুরোনো ধাঁচের কিছু লাইব্রেরি, JPA entity), সেখানে record চলবে না।

৯ · AI-এর যুগে — কখন record, কখন নয়, তা যাচাই আপনার কাজ

AI-কে “একটি bKash-ধাঁচের লেনদেনের মডেল Java-তে লিখে দাও” বললে অনেক সময় এখনো ৪০-৫০ লাইনের getter-setter-ভরা class আসে — কারণ AI যে কোটি লাইনের কোড থেকে শিখেছে, তার বেশিরভাগই record আসার আগের। আবার উল্টো ভুলও হয়: “আধুনিক Java” চাইলে AI সব কিছু record বানিয়ে দেয়, এমনকি ব্যালান্স-বদলানো account-ও। আর সবচেয়ে নীরব ভুল — List component-এ defensive copy না নেওয়া, যা কোনো টেস্টে সহজে ধরা পড়ে না।

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

• প্রতিটি record সত্যিই “মানই পরিচয়” ধরনের — কোনো ব্যালান্স, স্ট্যাটাস বা কাউন্টার সময়ের সাথে বদলানোর কথা নয়
• প্রতিটি List/Map/Set component compact constructor-এ copyOf দিয়ে কপি করা হয়েছে; কোনো array component নেই
• বৈধতার নিয়ম compact constructor-এ, আর অতিরিক্ত constructor বা factory সেই নিয়ম এড়াতে পারে না
• compact constructor-এ this.x = ... নেই; মান ঠিক করতে parameter-এ বসানো হয়েছে
• equals/hashCode/toString অকারণে override করা নেই (করা থাকলে কেন, তা স্পষ্ট)
• একটি ছোট পরীক্ষা চালিয়েছি: বাইরের list বদলে দেখেছি record-এর মান বদলায় কি না