Java sealed class আর pattern matching — বন্ধ টাইপ-পরিবার, নিরাপদ switch

১ · একটি পেমেন্টের তিনটি পরিণতি — বন্ধ টাইপ-পরিবার

ধরুন আপনি একটি মোবাইল ওয়ালেট অ্যাপের পেমেন্ট অংশ লিখছেন। ব্যবহারকারী “Pay” চাপলে সার্ভার থেকে উত্তর আসে, আর সেই উত্তর ঠিক তিন রকমের একটি। সফল — তখন সাথে আসে একটি লেনদেন নম্বর (TxID) আর টাকার পরিমাণ। ব্যর্থ — তখন আসে কারণ, যেমন “ব্যালান্স কম”। অপেক্ষমাণ — ব্যাংক এখনো নিশ্চিত করেনি, কয়েক সেকেন্ড পরে আবার দেখতে হবে। চতুর্থ কোনো রকম নেই। আর প্রতিটি রকমের সাথে আসা তথ্যও আলাদা।

পর্ব ২০-২১-এ আপনি এমন জিনিস মডেল করতেন একটি interface আর কয়েকটি class দিয়ে। কিন্তু সাধারণ interface সবার জন্য খোলা — যে কেউ, যেকোনো ফাইলে, implements PaymentResult লিখে পঞ্চম, ষষ্ঠ রকম বানাতে পারে। পেমেন্ট গেটওয়ের মতো plugin-ব্যবস্থায় এই খোলামেলা ভাবটাই চাই। কিন্তু পেমেন্টের ফল এমন জিনিস নয়। এর রকমগুলো ব্যবসার নিয়মেই স্থির। আর যে কোড ফলটা দেখে সিদ্ধান্ত নেয় — স্ক্রিনে কী দেখাবে, SMS যাবে কি না, আবার চেষ্টা করবে কি না — তার জানা দরকার যে তিনটির প্রতিটি সামলানো হয়েছে।

Java 17 আর 21 মিলে এর জন্য দুটি হাতিয়ার দিয়েছে। প্রথমটি sealed টাইপ — যা বলে “আমার উপ-টাইপ শুধু এরাই”। দ্বিতীয়টি pattern matching — যা দিয়ে switch প্রতিটি রকম চিনে নিয়ে তার ভেতরের তথ্য বের করে আনে। পর্ব ২৫-এর record-এর সাথে মিলিয়ে কোডটা দেখতে এরকম:

sealed interface PaymentResult permits Success, Failed, Pending {}
record Success(String txId, int amount) implements PaymentResult {}
record Failed(String reason) implements PaymentResult {}
record Pending(int waitSec) implements PaymentResult {}

String text = switch (result) {
    case Success(var txId, var amount) -> "সফল: " + amount + " টাকা";
    case Failed(var reason)            -> "ব্যর্থ: " + reason;
    case Pending(var waitSec)          -> waitSec + " সেকেন্ড পরে দেখুন";
};   // default নেই — compiler জানে এই তিনটিই সব

লক্ষ করুন কী নেই: কোনো instanceof-শিকল নেই, কোনো cast নেই, কোনো default নেই। প্রথম লাইনটি টাইপ-পরিবার বন্ধ করেছে। পরের তিন লাইন প্রতিটি রকমের ডেটা বলে দিয়েছে। আর switch প্রতিটি রকম খুলে তার অংশগুলোকে নাম দিয়েছে। পুরো পর্বটা এই ছোট কোডের ভেতরের নিয়মগুলো নিয়ে।

২ · sealed আর permits — কে উত্তরাধিকারী হতে পারবে

একটি class বা interface-এর আগে sealed লিখলে, আর permits-এর পরে নামের তালিকা দিলে, শুধু সেই নামগুলোই সরাসরি তাকে extends বা implements করতে পারে। এই তালিকাকে বলে permits clause. তালিকার বাইরের কেউ চেষ্টা করলে কী হয়, দেখুন। তালিকায় তিনটি নাম, কিন্তু কেউ চতুর্থ একটি record লিখল:

sealed interface PaymentResult permits Success, Failed, Pending {}
// ... Success, Failed, Pending আগের মতো ...
record Refunded(String txId) implements PaymentResult {}   // তালিকায় নেই

Main.java:5: error: class is not allowed to extend sealed class: PaymentResult (as it is not listed in its 'permits' clause)
record Refunded(String txId) implements PaymentResult {}
^
1 error

বার্তাটি পরিষ্কার: “permits তালিকায় নাম নেই, তাই extend করার অনুমতি নেই”। (এখানে interface হলেও বার্তায় “sealed class” লেখা — javac দুটোর জন্য একই বার্তা দেয়। OpenJDK 21-এ যাচাই করা; অনলাইন রানারে ফাইলের নাম prog.java দেখাতে পারে।) Sealed টাইপ বদলানোর অধিকার তাই তার মালিকের হাতে। নতুন রকম যোগ করতে হলে permits তালিকাতেও নাম লিখতে হবে — অর্থাৎ সিদ্ধান্তটা হবে জেনেশুনে, এক জায়গায়।

অনুমোদিত উপ-টাইপের তিনটি পছন্দ

Sealed টাইপ শুধু প্রথম স্তর বন্ধ করে। তার নিচে কী হবে, সেটা প্রতিটি অনুমোদিত উপ-টাইপকে নিজে ঘোষণা করতে হয়। আর ঘোষণা না করলে compiler মানে না। তিনটি পছন্দের যেকোনো একটি লিখতেই হবে:

non-sealed হলো Java-র প্রথম hyphen-যুক্ত keyword. Modifier না লিখলে কী হয়, দেখুন:

sealed class Shape permits Circle, Square {}
class Circle extends Shape {}          // final/sealed/non-sealed কোনোটাই নেই
final class Square extends Shape {}

Main.java:2: error: sealed, non-sealed or final modifiers expected
class Circle extends Shape {}
^
1 error

কেন এই কড়াকড়ি? কারণ sealed-এর পুরো মূল্য হলো compiler-এর জানা যে সব উপ-টাইপ কী কী। Circle চুপচাপ খোলা থাকলে যে কেউ class Oval extends Circle লিখে পরিবারে ঢুকে পড়ত। Java তাই আপনাকে প্রতিটি শাখার সিদ্ধান্ত লিখে দিতে বাধ্য করে। non-sealed লিখলেও exhaustiveness নষ্ট হয় না: switch-এ case Custom c লিখলে Custom-এর সব subclass, এমনকি পরে কেউ বানালেও, ওই এক case-এ ধরা পড়ে।

কোথায় থাকতে পারে, আর কখন permits বাদ দেওয়া যায়

• একই module বা package: অনুমোদিত উপ-টাইপগুলোকে sealed টাইপের কাছাকাছি থাকতে হয়। আপনার কোড কোনো নামযুক্ত module-এ থাকলে সবাইকে সেই module-এ থাকতে হবে; module ছাড়া সাধারণ প্রজেক্টে (unnamed module) সবাইকে একই package-এ থাকতে হবে। কারণ compiler-কে একসাথে পুরো পরিবার দেখতে হয়।
• একই ফাইলে থাকলে permits ঐচ্ছিক: সব উপ-টাইপ যদি একই .java ফাইলে থাকে, sealed interface Shape {} লিখলেই চলে। Compiler ফাইলের ভেতরে যারা Shape-কে implement করেছে, তাদের নিয়েই তালিকা বানিয়ে নেয়। ছোট টাইপ-পরিবারে (যেমন এই পর্বের উদাহরণগুলো) এটাই সুবিধাজনক। তবে বড় প্রজেক্টে স্পষ্ট permits লিখে রাখলে পাঠক এক নজরে পুরো পরিবার দেখতে পান।
• প্রতিটি অনুমোদিত উপ-টাইপকে সরাসরি extend/implement করতেই হবে: তালিকায় নাম আছে কিন্তু class-টি আসলে extend করেনি — এটাও compile error.

৩ · Type pattern — instanceof থেকে switch

পর্ব ২০-এ দেখেছেন Java 16-এর instanceof pattern: if (r instanceof Success s) — পরীক্ষা সফল হলে s নামে cast করা ভ্যারিয়েবল তৈরি হয়। Success s অংশটির নাম type pattern: একটি টাইপ, আর মিল হলে যে নামে মানটি পাওয়া যাবে। তিনটি রকম সামলাতে এভাবে লিখলে দাঁড়ায় একটি শিকল:

// শুধু instanceof দিয়ে (Java 16+)
String text;
if (r instanceof Success s)      text = "সফল: " + s.amount();
else if (r instanceof Failed f)  text = "ব্যর্থ: " + f.reason();
else if (r instanceof Pending p) text = "অপেক্ষা: " + p.waitSec();
else throw new IllegalStateException("অজানা ফল");   // সত্যিই কি দরকার?

Cast-এর ঝামেলা গেছে, কিন্তু দুটি সমস্যা রয়ে গেছে। এক, শেষ লাইনের else throw — compiler জানে না যে আর কোনো রকম নেই, তাই আপনাকে একটি “অসম্ভব” শাখা লিখতে হয়। দুই, কাল Refunded যোগ হলে এই শিকল চুপচাপ compile হবে, আর ভুলটা ধরা পড়বে চলার সময়, হয়তো কোনো গ্রাহকের ফোনে। Java 21-এ একই pattern switch-এর case-এ বসানো যায় (switch expression, পর্ব ১০):

// Java 21: pattern matching for switch (JEP 441)
String text = switch (r) {
    case Success s -> "সফল: " + s.amount();
    case Failed f  -> "ব্যর্থ: " + f.reason();
    case Pending p -> "অপেক্ষা: " + p.waitSec();
};

পার্থক্যটা শুধু দেখতে সুন্দর হওয়া নয়। switch একটি একক কাঠামো, তাই compiler পুরোটা একসাথে বিচার করতে পারে: সব রকম ঢাকা হয়েছে কি না (অংশ ৫), কোনো case অন্যটির আড়ালে চাপা পড়েছে কি না (অংশ ৬)। if-else-শিকল আলাদা আলাদা statement, তাই সেখানে এই বিচার হয় না। পর্ব ১০-এ switch চলত শুধু সংখ্যা, String বা enum-এর ওপর। এখন যেকোনো reference টাইপের ওপর চলে, আর case মানে “এই মান কি এই আকারের?”

৪ · Record pattern — ডেটা খুলে দেখা, guard আর case null

Type pattern-এ case Success s লিখে তারপর s.txId(), s.amount() ডাকতে হয়। Record-এর বেলায় Java 21 আরেক ধাপ এগিয়েছে: record যেভাবে তৈরি হয়, ঠিক সেই আকারেই তাকে খুলে ফেলা যায়। new Success("TX9K2", 500) দিয়ে বানালে case Success(var txId, var amount) দিয়ে খোলা যায়। এর নাম record pattern (JEP 440). মিল হলে record-এর প্রতিটি component নিজের নামে একটি ভ্যারিয়েবলে চলে আসে। var-এর জায়গায় আসল টাইপও লেখা যায়: case Success(String txId, int amount).

নিচের প্রোগ্রামে পাঁচটি উত্তর এসেছে — একটি null সহ। বড় অঙ্কের সফল লেনদেনের জন্য আলাদা বার্তা চাই, তাই একটি guard (when) আছে। চালিয়ে দেখুন:

sealed interface PaymentResult permits Success, Failed, Pending {}
record Success(String txId, int amount) implements PaymentResult {}
record Failed(String reason) implements PaymentResult {}
record Pending(int waitSec) implements PaymentResult {}
class Main {
    static String message(PaymentResult r) {
        return switch (r) {
            case null -> "কোনো উত্তর আসেনি";
            case Success(var txId, var amount) when amount >= 10000 ->
                "বড় লেনদেন সফল: " + amount + " টাকা, TxID " + txId;
            case Success(var txId, var amount) -> "সফল: " + amount + " টাকা, TxID " + txId;
            case Failed(var reason) -> "ব্যর্থ: " + reason;
            case Pending(var waitSec) -> waitSec + " সেকেন্ড পরে আবার দেখুন";
        };
    }
    public static void main(String[] args) {
        PaymentResult[] results = { new Success("TX9K2", 500), new Failed("ব্যালান্স কম"),
            new Pending(30), new Success("TX7Q1", 15000), null };
        for (PaymentResult r : results) {
            System.out.println(message(r));
        }
    }
}

প্রতিটি উত্তরের জন্য switch কোন case-এ থামল, আর কোন ভ্যারিয়েবলে কী বসল — ধাপে ধাপে দেখুন:

1return switch (r) {2  case null -> "কোনো উত্তর আসেনি";3  case Success(var txId, var amount)4      when amount >= 10000 -> "বড় লেনদেন …";5  case Success(var txId, var amount) -> "সফল …";6  case Failed(var reason) -> "ব্যর্থ: " + reason;7  case Pending(var waitSec) -> waitSec + " সেকেন্ড …";8};

Nested record pattern আর instanceof-এ record pattern

Record-এর component নিজেও একটি record হলে pattern-এর ভেতরে আরেকটি pattern বসানো যায়। ধরুন একটি ডেলিভারি অ্যাপে record Rider(String name, String phone) আর record PickedUp(Rider rider, String hub). তখন case PickedUp(Rider(var name, var phone), var hub) -> এক লাইনে দুই স্তর খুলে দেয়। অংশ ৭-এ expression গাছে এর আসল শক্তি দেখবেন। Record pattern instanceof-এও চলে: if (o instanceof Success(var id, var amt) && amt > 1000).

৫ · Exhaustiveness — compiler প্রমাণ করে কোনো রকম বাদ পড়েনি

পর্ব ১০-এ দেখেছেন, enum-এর ওপর switch expression-এ সব মান না থাকলে compiler আপত্তি করে। এই নিয়মের নাম exhaustiveness. Sealed টাইপে একই নিয়ম আরও শক্তিশালী হয়ে কাজ করে। Compiler permits তালিকা পড়ে জানে PaymentResult মানে ঠিক Success, Failed আর Pending. তিনটিরই case থাকলে switch সম্পূর্ণ — default লাগে না। একটি বাদ পড়লে:

Main.java:8: error: the switch expression does not cover all possible input values
        return switch (r) {
               ^
1 error

মান ফেরত না দেওয়া switch statement-এও, case-এ pattern থাকলেই, একই নিয়ম খাটে। তখন বার্তায় লেখা থাকে “the switch statement does not cover all possible input values”. (দুটিই OpenJDK 21-এ যাচাই করা।) আর মনে রাখুন, guard-ওয়ালা case exhaustiveness-এর হিসাবে গোনা হয় না। শুধু case Success(…) when amount >= 10000 থাকলে compiler ধরে নেয় ছোট অঙ্কের Success বাকি রয়ে গেছে, আর একই error দেয়।

এবার আসল দৃশ্য। ছয় মাস পরে ব্যবসায় নতুন নিয়ম এল: টাকা ফেরত (refund) হলে আলাদা অবস্থা দেখাতে হবে। আপনি Refunded যোগ করলেন। এখন কী হয়, ধাপে ধাপে দেখুন:

PaymentResult.java   sealed … permits Success, Failed, Pending
Screen.java          message(r)  → switch: Success, Failed, Pending
Sms.java             smsText(r)  → switch: Success, Failed, Pending
Report.java          label(r)    → switch: Success, default

sealed interface PaymentResult
    permits Success, Failed, Pending, Refunded {}
record Refunded(String txId, int amount) implements PaymentResult {}

Screen.java:4: error: the switch expression does not cover all possible input values
Sms.java:6: error: the switch expression does not cover all possible input values
2 errors

return switch (r) {
    case Success s -> "PAID";
    default -> "NOT PAID";   // Refunded-ও এখানে — ভুল লেবেল!
};

case Refunded(var txId, var amount) ->
    amount + " টাকা ফেরত দেওয়া হয়েছে";
// Report.java: default সরিয়ে প্রতিটি রকম লিখুন

চলার সময় দুটি নিরাপত্তা

• null: sealed পরিবার সম্পূর্ণ হলেও null তার সদস্য নয়। case null না থাকলে null এলে switch সরাসরি NullPointerException ছোড়ে। OpenJDK 21-এ trace-এর প্রথম লাইন Exception in thread "main" java.lang.NullPointerException, তার নিচে java.util.Objects.requireNonNull থেকে আসা একটি লাইন। null আসতে পারে এমন জায়গায় case null -> লিখুন, অথবা case null, default -> একসাথে লিখুন। আরও ভালো উপায় হলো, null যেন ঢুকতেই না পারে এমন নকশা (পর্ব ৩৬-এর Optional).
• আলাদা করে compile করা কোড: ধরুন PaymentResult একটি library-তে আছে, আর আপনার অ্যাপের switch আগের সংস্করণ দেখে compile হয়েছিল। পরে library-তে নতুন রকম এল, কিন্তু আপনার অ্যাপ আবার compile হয়নি। তখন চলার সময় অজানা রকম এলে Java চুপ থাকে না। Compiler আগেই সম্পূর্ণ switch-এর ভেতরে একটি লুকানো শাখা বসিয়ে রেখেছিল, যা MatchException ছোড়ে। ফলে ভুলটা নীরবে চলে না, চোখে পড়ে।

৬ · ক্রম, guard আর dominance — কোন case আগে লিখবেন

Pattern switch ওপর থেকে নিচে পরীক্ষা করে, আর প্রথম মিলটিই জেতে। তাই ক্রম গুরুত্বপূর্ণ। কিন্তু Java একটি ভুল ক্রম নিজেই ধরে। কোনো case যদি এমন হয় যে তার আগের কোনো case তার সব মান আগেই ধরে ফেলবে, তাহলে সেটি কোনোদিন চলতে পারবে না। এমন মৃত কোড Java মানে না। এই নিয়মের নাম dominance:

return switch (r) {
    case Success s -> "ok " + s.txId();
    case Success s when s.amount() > 10000 -> "big";   // কখনো পৌঁছাবে না
    case Failed f  -> "fail " + f.reason();
    case Pending p -> "wait " + p.waitSec();
};

Main.java:9: error: this case label is dominated by a preceding case label
            case Success s when s.amount() > 10000 -> "big";
                 ^
1 error

প্রথম case সব Success ধরে ফেলে, শর্ত ছাড়াই। তাই দ্বিতীয়টি “dominated” — চাপা পড়া। Record pattern-এও হুবহু একই বার্তা আসে। আর টাইপের ক্ষেত্রেও একই কথা: case Object o-এর পরে case Integer i লিখলে একই error, কারণ প্রতিটি Integer আগেই একটি Object. (সবগুলো OpenJDK 21-এ যাচাই করা।) নিয়মটা মনে রাখার সহজ উপায় হলো পর্ব ১০-এর else-if সারির নিয়ম: নির্দিষ্ট আগে, সাধারণ পরে। এখানে পার্থক্য একটাই — compiler নিজে পাহারা দেয়।

Guard কতটা ব্যবহার করবেন

when-এর পরে যেকোনো boolean শর্ত লেখা যায়, আর pattern-এর ভ্যারিয়েবল সেখানে ব্যবহার করা যায়। কিন্তু compiler guard-এর ভেতরে কী আছে তা বিশ্লেষণ করে না। তাই when amount >= 10000 আর when amount < 10000 — দুটো একসাথে সব সংখ্যা ঢাকলেও compiler তা জানে না, আর guard-ছাড়া একটি case চাইবে। ব্যবহারিক পরামর্শ: guard রাখুন ব্যতিক্রমের জন্য, আর প্রতিটি রকমের জন্য guard-ছাড়া একটি “স্বাভাবিক” case রাখুন।

৭ · sealed + record = algebraic data type — একটি ছোট ক্যালকুলেটর

এতক্ষণ যা বানালেন, তার একটি পুরোনো ও সুন্দর নাম আছে: algebraic data type. নামটা ভয়ের নয়। দুটি সরল গঠন জুড়ে বানানো টাইপ:

(নাম দুটো গণিত থেকে। ধরুন একটি record-এ দুটি boolean আছে। তাহলে মোট সম্ভাব্য মান ২ × ২ = ৪, তাই “product” বা গুণফল। আর sealed পরিবারের মোট মান হয় প্রতিটি রকমের মানের যোগফল, তাই “sum”.) এই দুই গঠন দিয়ে আশ্চর্য রকম অনেক কিছু মডেল করা যায়, এমনকি এমন ডেটাও যা নিজের ভেতরে নিজেকেই ধারণ করে। একটি গাণিতিক expression ভাবুন: 2 + 3 * 4. এটি হয় একটি সংখ্যা, অথবা দুটি expression-এর যোগ, অথবা দুটি expression-এর গুণ। লক্ষ করুন, “expression”-এর সংজ্ঞায় আবার “expression” আছে — এটি একটি গাছ:

sealed interface Expr permits Num, Add, Mul {}
record Num(int value) implements Expr {}
record Add(Expr left, Expr right) implements Expr {}
record Mul(Expr left, Expr right) implements Expr {}
class Main {
    static int eval(Expr e) {
        return switch (e) {
            case Num(var v) -> v;
            case Add(var l, var r) -> eval(l) + eval(r);
            case Mul(var l, var r) -> eval(l) * eval(r);
        };
    }
    static String show(Expr e) {
        return switch (e) {
            case Num(var v) -> String.valueOf(v);
            case Mul(Num(var a), Num(var b)) when a == 1 -> String.valueOf(b);
            case Add(var l, var r) -> "(" + show(l) + " + " + show(r) + ")";
            case Mul(var l, var r) -> show(l) + " * " + show(r);
        };
    }
    public static void main(String[] args) {
        Expr e = new Add(new Num(2), new Mul(new Num(3), new Num(4)));
        System.out.println(show(e) + " = " + eval(e));
        Expr f = new Mul(new Num(1), new Num(7));
        System.out.println(show(f) + " = " + eval(f));
        System.out.println(e);
    }
}

eval(Add(Num 2, Mul(Num 3, Num 4))) ভেতরে কীভাবে চলে, ধাপে ধাপে দেখুন। Call stack-এ কোন ডাক জমছে আর কোনটা ফল ফেরত দিচ্ছে, সেদিকে নজর রাখুন:

1static int eval(Expr e) {2  return switch (e) {3    case Num(var v) -> v;4    case Add(var l, var r) -> eval(l) + eval(r);5    case Mul(var l, var r) -> eval(l) * eval(r);6  };7}

এখন ভাবুন, এই ক্যালকুলেটরে নতুন কাজ যোগ করা কত সহজ: show একটি নতুন method, simplify আরেকটি, countNodes আরেকটি — Num, Add, Mul record-এ একটি লাইনও না ছুঁয়ে। আর নতুন রকম (ধরুন Sub) যোগ করলে compiler প্রতিটি method দেখিয়ে দেবে যেখানে Sub-এর case লাগবে (অনুশীলন ৩)।

বাস্তবে কোথায় এই নকশা

৮ · Polymorphism না pattern matching? — Expression Problem আবার

পর্ব ২০-এ শিখেছিলেন, instanceof-শিকল দেখলে polymorphism-এ ভাঙুন — প্রতিটি টাইপ নিজের আচরণ নিজের method-এ রাখুক। আর এই পর্বে উল্টো কথা শুনছেন: টাইপ দেখে switch করুন। দুটোই কি ঠিক? হ্যাঁ — কারণ দুটো দুই রকম পরিবর্তনের জন্য তৈরি। পর্ব ২০-এর ভাবনার প্রশ্ন ৪-এ দেখা Expression Problem-এর ছকটা মনে করুন: সারিতে টাইপ, কলামে কাজ।

মূল প্রশ্নটি তাই: আপনার সিস্টেম কোন দিকে বেশি বাড়বে? নতুন নতুন পেমেন্ট পদ্ধতি আসবে, কিন্তু প্রতিটির কাজ (fee, pay, refund) মোটামুটি স্থির — তাহলে polymorphism. পেমেন্টের ফল তিন-চার রকমেই থাকবে, কিন্তু সেই ফল দিয়ে কাজ বাড়তেই থাকবে (স্ক্রিন, SMS, রিপোর্ট, অডিট লগ, অ্যানালিটিক্স) — তাহলে sealed + pattern matching. পুরোনো OOP ভাষায় দ্বিতীয় ধরনের প্রয়োজন মেটাতে লোকে Visitor pattern লিখত। তাতে প্রতিটি class-এ একটি accept method আর প্রতিটি কাজের জন্য একটি visitor class লাগত। Sealed + switch সেই একই কাজ অনেক কম আনুষ্ঠানিকতায় করে।

Java-র ভাষা-স্থপতি Brian Goetz ২০২২ সালের একটি প্রবন্ধে এই দ্বিতীয় ধারাকে Java-র প্রেক্ষাপটে data-oriented programming নামে ব্যাখ্যা করেন (নামটি অন্য প্রেক্ষাপটে আগেও ব্যবহৃত হয়েছে)। এটা OOP-এর বদলি নয়, পাশে আরেকটি হাতিয়ার। বড় সিস্টেমের সীমানায় — যেখানে বাইরের দুনিয়া থেকে ডেটা আসে বা বাইরে যায় (API, ফাইল, মেসেজ) — ডেটা প্রায়ই নিছক ডেটা। সেখানে record আর sealed পরিষ্কার। আর ভেতরের জটিল আচরণ, যেখানে state লুকিয়ে রাখা আর বদলানো দরকার, সেখানে class আর polymorphism. একই প্রজেক্টে দুটোই থাকে (ভাবনার প্রশ্ন ৩)।

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

AI কোড-সহকারীরা প্রচুর পুরোনো Java কোড দেখে শিখেছে। Java 8 আর 11 যুগের কোড সেখানে অনেক বেশি, Java 21-এর তুলনায়। তাই “পেমেন্টের ফল দেখে বার্তা দেখাও” বললে প্রায়ই পাবেন instanceof-শিকল আর প্রতিটি শাখায় cast, শেষে একটি else throw. বা একটি String status field আর switch (status), যেখানে "SUCESS"-এর মতো বানান ভুল compile-এ ধরা পড়ে না। আবার উল্টোটাও ঘটে: যেখানে বাইরের লোককে নতুন টাইপ যোগ করতে দিতে হবে (plugin), সেখানেও AI সবকিছু sealed করে দেয়।

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

• টাইপ-পরিবারটা সত্যিই বন্ধ কি না নিজে ভেবেছি — বাইরের কেউ নতুন রকম আনবে না
• Sealed টাইপের ওপর কোনো switch-এ default নেই
• নতুন একটি রকম যোগ করে compile করে দেখেছি — compiler সব অসম্পূর্ণ switch দেখিয়েছে
• কোনো instanceof-শিকল বা হাতে লেখা cast নেই
• guard-ওয়ালা case guard-ছাড়া case-এর আগে, আর null-এর ব্যবস্থা ভেবে রাখা হয়েছে
• কোডটি --enable-preview ছাড়াই Java 21-এ compile হয়