static আর final — class-এর ভাগের জিনিস আর না-বদলানো মান

১ · দুটি ছোট শব্দ, দুটি আলাদা প্রশ্ন

পর্ব ১৫ থেকে ১৭-তে আপনি class থেকে object বানিয়েছেন, constructor দিয়ে সাজিয়েছেন, আর private দিয়ে ভেতরের ডেটা লুকিয়েছেন। প্রতিটি Student object-এর নিজের name, নিজের roll. কিন্তু কিছু তথ্য কোনো একজন student-এর নয়। “এ পর্যন্ত মোট কতজন ভর্তি হয়েছে?” — এই সংখ্যাটি রহিমের, না মিতুর? কারোরই না। এটা পুরো class-এর তথ্য।

Java-তে এই ধরনের জিনিস চিহ্নিত করার keyword হলো static. আর এই পর্বের দ্বিতীয় keyword final একেবারে আলাদা একটি প্রশ্নের উত্তর দেয়। দুটিকে আলাদা করে মনে রাখুন:

দুটি keyword একসাথেও বসতে পারে: static final double VAT_RATE = 0.15; — একটিই কপি (static), আর কখনো বদলাবে না (final). এটাই Java-তে constant লেখার রীতি, অংশ ৫-এ বিস্তারিত। কিন্তু আগে দেখা যাক static জিনিস মেমরিতে আসলে কোথায় থাকে। নিচের Student class-এ school হলো static, name হলো সাধারণ instance field:

class-এর এলাকা (Student)        heap
┌──────────────────────────┐
│ static school = "Dhaka"  │    (এখনো কোনো object নেই)
└──────────────────────────┘
object না থাকলেও static field-এর জায়গা তৈরি

class-এর এলাকা (Student)        heap
┌──────────────────────────┐    a ─▶ [ name = "Rahim" ]
│ static school = "Dhaka"  │    b ─▶ [ name = "Mitu"  ]
└──────────────────────────┘    c ─▶ [ name = "Karim" ]
name তিনটি, তিনটি object-এর ভেতরে; school একটিই, বাইরে

class-এর এলাকা (Student)        heap
┌──────────────────────────┐    a ─▶ [ name = "Rahima" ]
│ static school = "Dhaka"  │    b ─▶ [ name = "Mitu"   ]
└──────────────────────────┘    c ─▶ [ name = "Karim"  ]
instance field বদলালে শুধু সেই object বদলায়

class-এর এলাকা (Student)        heap
┌──────────────────────────┐    a ─▶ [ name = "Rahima" ]
│ static school = "Rajshahi"│    b ─▶ [ name = "Mitu"   ]
└──────────────────────────┘    c ─▶ [ name = "Karim"  ]
একটি বদল — a, b, c তিনজনই এখন "Rajshahi" দেখে

b.school   ──┐
c.school   ──┼──▶  Student.school = "Rajshahi"
Student.school┘
object দিয়ে লিখলেও compiler আসলে Student.school পড়ে — বিভ্রান্তিকর, তাই এড়িয়ে চলুন

২ · static field — সবার জন্য একটিই কপি

যে field-এর আগে static লেখা, সেটাই static field (একে class variable-ও বলে)। সবচেয়ে প্রচলিত দুটি ব্যবহার — কয়টি object তৈরি হলো তা গোনা, আর প্রতিটি নতুন object-কে একটি অনন্য ক্রমিক নম্বর দেওয়া। কলেজে ভর্তির সময় অফিসের রেজিস্টার খাতা ভাবুন: খাতা একটিই, শেষ রোল কত দেওয়া হয়েছে তা সেখানে লেখা। নতুন কেউ এলে সেই সংখ্যার পরেরটা পায়, আর খাতায় সংখ্যাটা এক বাড়ে।

class Student {
    private static int nextRoll = 101;   // class-এর একটিই কপি
    private static int count = 0;
    private final int roll;              // প্রতিটি object-এর নিজের
    private final String name;

    Student(String name) {
        this.name = name;
        this.roll = nextRoll++;
        count++;
    }
    static int getCount() { return count; }
    String info() { return roll + " - " + name; }
}

class Main {
    public static void main(String[] args) {
        System.out.println("শুরুতে: " + Student.getCount());
        Student[] all = { new Student("Rahim"), new Student("Mitu"), new Student("Karim") };
        for (Student s : all) System.out.println(s.info());
        System.out.println("মোট student: " + Student.getCount());
    }
}

এবার ধাপে ধাপে দেখুন, প্রতিটি new-এর সময় ভাগের দুটি static field আর নতুন object-এর roll কীভাবে বদলায়:

1private static int nextRoll = 101;2private static int count = 0;3Student(String name) {4    this.roll = nextRoll++;5    count++;6}7Student a = new Student("Rahim");8Student b = new Student("Mitu");9Student c = new Student("Karim");10a.info(); b.info(); c.info();

৩ · static method — object ছাড়াই কাজ

পর্ব ১২-এ আপনি যত method লিখেছেন, সবই ছিল static method. তখন object জানা ছিল না, তাই সেটাই একমাত্র পথ ছিল। এখন প্রশ্নটা বদলেছে: কখন একটি method static হওয়া উচিত? উত্তর — যখন কাজটি কোনো নির্দিষ্ট object-এর অবস্থার ওপর নির্ভর করে না, শুধু argument নিয়েই করা যায়।

Java-র নিজের library-তে এর সবচেয়ে পরিচিত উদাহরণ Math class: Math.max(3, 7), Math.sqrt(2), Math.round(4.6). দুটি সংখ্যার বড়টি বের করতে কোনো “Math object” লাগে না — new Math() লেখাই যায় না, কারণ Math-এর constructor private. এমন class, যার সব method static আর যার object বানানোর কোনো মানে নেই, তাকে বলে utility class. Arrays, Collections, Objects — সবাই এই দলের।

final class TaxCalculator {
    static final double VAT_RATE = 0.15;   // constant (অংশ ৫)
    private TaxCalculator() { }            // কেউ object বানাতে পারবে না

    static double vat(double amount)      { return amount * VAT_RATE; }
    static double withVat(double amount)  { return amount + vat(amount); }
}

double total = TaxCalculator.withVat(1000);   // object ছাড়াই, class-এর নাম দিয়ে

তিনটি জিনিস খেয়াল করুন: class-টি final (কেউ extend করবে না), constructor private (কেউ object বানাবে না), আর সব method static. এটাই utility class-এর প্রচলিত ছাঁচ।

কেন main static

প্রোগ্রাম শুরুর মুহূর্তে কোনো object নেই। JVM-কে কোথাও থেকে শুরু করতে হবে। যদি main একটি instance method হতো, তাহলে JVM-কে আগে new Main() করতে হতো — কিন্তু কোন constructor দিয়ে? তার argument কী? সেই constructor নিজেই exception দিলে? Java-র নকশাকারেরা এই প্রশ্নগুলো এড়াতে নিয়ম করেছিলেন: শুরুর method হবে public static void main(String[] args) — যাতে JVM শুধু class load করে, কোনো object না বানিয়েই, সরাসরি Main.main(args) ডাকতে পারে। (Java 21-এ এই নিয়ম শিথিল করার একটি preview feature এসেছিল, যা পরে Java 25-এ স্থায়ী হয় — ভাবনার প্রশ্ন ১-এ দেখুন।)

static method যা পারে না

Static method কোনো object-এর হয়ে চলে না। তাই তার কাছে this নেই — “কোন object?” প্রশ্নের কোনো উত্তর নেই। এর সরাসরি ফল: static method সরাসরি কোনো instance field পড়তে বা instance method ডাকতে পারে না। নতুনদের সবচেয়ে চেনা compile error এখান থেকেই আসে:

class Student {
    String name = "Rahim";
    static void show() {
        System.out.println(name);      // কার name?
    }
}
class Main {
    void greet() { }
    public static void main(String[] args) {
        greet();                       // কোন object-এর greet?
        System.out.println(this);      // static-এ this নেই
    }
}

Main.java:4: error: non-static variable name cannot be referenced from a static context
        System.out.println(name);
                           ^
Main.java:10: error: non-static method greet() cannot be referenced from a static context
        greet();
        ^
Main.java:11: error: non-static variable this cannot be referenced from a static context
        System.out.println(this);
                           ^
3 errors

মেসেজগুলো OpenJDK 21-এ যাচাই করা। “static context” মানে static method বা static block-এর ভেতরের জায়গা, যেখানে কোনো this নেই। সমাধান দুটি, আর কোনটা ঠিক তা নির্ভর করে অর্থের ওপর: (১) একটি object বানিয়ে তার মাধ্যমে ডাকুন — new Main().greet(); বা s.name; অথবা (২) যদি জিনিসটা সত্যিই কোনো object-এর নয়, তাহলে সেটাকে static করুন। ভুল পথ হলো error সরাতে চোখ বন্ধ করে সব কিছুতে static বসিয়ে দেওয়া — অংশ ৯-এ দেখবেন, AI ঠিক এটাই প্রায়ই করে।

static import — পরিমিত ব্যবহার

বারবার Math. লিখতে ক্লান্ত লাগলে static import ব্যবহার করা যায়:

import static java.lang.Math.sqrt;    // শুধু একটি নাম — ভালো
import static java.lang.Math.*;       // সব নাম — সাবধানে

double d = sqrt(a * a + b * b);       // Math. লিখতে হলো না

সুবিধা আছে, ঝুঁকিও আছে। max(x, y) পড়ে পাঠক বুঝবেন না এটা Math.max, না আপনার নিজের class-এর কোনো method. Oracle-এর নিজের নির্দেশনাও বলে static import “খুব কম” ব্যবহার করতে — যেখানে একই class-এর constant বা method একটি ফাইলে বারবার আসে, শুধু সেখানে। JUnit টেস্টে import static org.junit.jupiter.api.Assertions.*; এর একটি প্রচলিত, গ্রহণযোগ্য ব্যবহার (পর্ব ৪৭)।

৪ · static block আর class কখন জেগে ওঠে

কিছু static field-এর শুরুর মান এক লাইনে দেওয়া যায় না — যেমন একটি টেবিল ভরাট করা, বা একটি ফাইল থেকে কনফিগারেশন পড়া। এর জন্য আছে static initializer block: class-এর ভেতরে static { … }. এই block চলে একবারই, যখন class প্রথমবার initialize হয়।

class District {
    static final java.util.Map<String, Integer> CODES = new java.util.TreeMap<>();
    static {
        CODES.put("Dhaka", 1);
        CODES.put("Rajshahi", 2);
        System.out.println("District প্রস্তুত");   // একবারই ছাপবে
    }
    static int codeOf(String name) { return CODES.get(name); }
}

“প্রথমবার initialize” ঠিক কখন? Class initialization ঘটে class-এর প্রথম “সক্রিয় ব্যবহারে” — প্রথম new, প্রথম static method ডাক, বা প্রথম static field পড়া/লেখা (Java Language Specification §12.4.1). শুধু ভ্যারিয়েবল ঘোষণা করলে (District d;) হয় না। আর একটি চমকপ্রদ ব্যতিক্রম আছে, পরের অংশে যার কারণ বুঝবেন। ধাপে ধাপে দেখুন:

static nested class — এক ঝলক

Class-এর ভেতরেও class লেখা যায়। ভেতরের class-এর আগে static থাকলে সেটা static nested class — বাইরের class-এর কোনো object-এর সাথে বাঁধা নয়, শুধু নামের দিক থেকে তার ভেতরে থাকে, যেমন Map.Entry. static না থাকলে সেটা inner class, যার প্রতিটি object একটি বাইরের object-এর সাথে যুক্ত। দুটির পার্থক্য আর কখন কোনটা — পর্ব ২৭-এ।

৫ · final ভ্যারিয়েবল — একবার মান, আর নয়

এবার দ্বিতীয় keyword. যেকোনো ভ্যারিয়েবলের আগে final লিখলে compiler নিশ্চিত করে যে তাতে ঠিক একবার মান বসবে। দ্বিতীয়বার চেষ্টা করলে compile error. চারটি জায়গায় এটা দেখা যায়:

Instance field-এর ক্ষেত্রটি সবচেয়ে কাজের। অংশ ২-এর roll ঘোষণার সময় কোনো মান পায়নি — এমন final field-কে বলে blank final. compiler কড়া পাহারা দেয়: প্রতিটি constructor-এর প্রতিটি পথে ঠিক একবার মান বসাতেই হবে। একটি constructor ভুলে গেলে:

Main.java:4: error: variable roll might not have been initialized
    Student() { }
                ^

আর মান বসানোর পর নতুন মান দিতে গেলে (মেসেজ দুটিই OpenJDK 21-এ যাচাই করা):

error: cannot assign a value to final variable roll
error: cannot assign a value to static final variable VAT_RATE

এর মূল্য কী? roll final হওয়ায় class-এর পাঠক এক নজরে জানেন — একবার ভর্তি হলে কোনো student-এর রোল আর বদলায় না। এটা একটি invariant, যা compiler নিজে পাহারা দেয়; কোনো setter ভুল করে লিখে ফেলাও সম্ভব নয়। Local variable-এ final লেখা ঐচ্ছিক রুচির ব্যাপার — কেউ লম্বা method-এ পড়ার সুবিধার জন্য লেখেন, কেউ লেখেন না।

Constant — static final আর UPPER_SNAKE_CASE

যে মান পুরো প্রোগ্রামে একটিই আর কখনো বদলায় না, সেটা static final. Java-র রীতি অনুযায়ী এর নাম লেখা হয় সব বড় হাতের অক্ষরে, শব্দের মাঝে আন্ডারস্কোর দিয়ে — UPPER_SNAKE_CASE: VAT_RATE, MAX_STUDENTS, Math.PI, Integer.MAX_VALUE. নাম দেখেই পাঠক বোঝেন, এটা বদলায় না। একটি দোকানের বিলিং প্রোগ্রামের constant টেবিল এমন হতে পারে:

final class ShopConfig {
    private ShopConfig() { }
    static final String SHOP_NAME     = "Rahman Store";
    static final double VAT_RATE      = 0.15;
    static final int    MAX_ITEMS     = 50;     // এক রসিদে সর্বোচ্চ
    static final long   FREE_DELIVERY = 100_000; // পয়সায়, মানে ১০০০ টাকা
}

এখন প্রোগ্রামের কোথাও 0.15 বা 50-এর মতো রহস্যময় সংখ্যা (magic number) থাকবে না; থাকবে ShopConfig.VAT_RATE — নামই অর্থ বলে দেয়, আর হার বদলালে বদলাতে হয় এক জায়গায়। তবে একটি প্রশ্ন নিজেকে করুন: মানটি কি সত্যিই কখনো বদলায় না? π বদলায় না। কিন্তু VAT-এর হার সরকারের বাজেটে বদলাতে পারে, আর তখন constant বদলানো মানে পুরো প্রোগ্রাম আবার compile ও deploy করা। যে মান বাস্তবে বদলায়, বড় সিস্টেমে তা সাধারণত কনফিগারেশন ফাইল বা ডেটাবেস থেকে পড়া হয় — অনুশীলন ৪-এ এটা নিয়ে ভাববেন।

Compile-time constant আর inlining

অংশ ৪-এর stepper-এ Config.MAX পড়লেও Config class জাগেনি। কারণ: যে static final field-এর টাইপ primitive বা String, আর মান একটি constant expression (যেমন 5, "Rahman Store", 60 * 60), সেটা একটি compile-time constant. compiler এর ব্যবহার দেখলেই মানটি সরাসরি ব্যবহারকারী class-এর bytecode-এ বসিয়ে দেয় — একে বলে inlining.

এর একটি বাস্তব ফাঁদ আছে। ধরুন একটি library-তে static final int TIMEOUT = 30;, আর আপনার কোড সেটা ব্যবহার করে। Library-র লেখক মানটি 60 করলেন, শুধু library আবার compile করলেন। আপনার পুরোনো compile করা class কিন্তু এখনো 30-ই ব্যবহার করবে — কারণ 30 সংখ্যাটি আপনার bytecode-এর ভেতরে বসানো, library থেকে পড়া হয় না। তাই যে মান ভবিষ্যতে বদলাতে পারে, public API-তে তাকে compile-time constant বানানো বিপজ্জনক; সেখানে একটি static method (getTimeout()) নিরাপদ।

৬ · final reference ≠ immutable object

এই পর্বের সবচেয়ে জরুরি, আর সবচেয়ে বেশি ভুল বোঝা কথা: final ভ্যারিয়েবলকে আটকায়, object-কে নয়। পর্ব ১২-তে দেখেছেন, object ভ্যারিয়েবলে থাকে শুধু একটি reference — ঠিকানা। final StringBuilder sb মানে ঠিকানাটি বদলানো যাবে না; সেই ঠিকানার বাড়ির ভেতরের আসবাব বদলানো যাবে কি না, তা ঠিক করে object নিজে।

stack                      heap
sb (final) ══════▶  [ StringBuilder: "cha" ]
══ মানে তীরটি গাঁথা — আর ঘোরানো যাবে না

stack                      heap
sb (final) ══════▶  [ StringBuilder: "cha + biscuit" ]
✔ বৈধ — একই object, ভেতরটা বদলাল

stack                      heap
sb (final) ══════▶  [ StringBuilder: "cha + biscuit" ]
            ✗ ─ ─▶  [ StringBuilder: "coffee" ]
error: cannot assign a value to final variable sb

stack                      heap
sb (final) ══════▶  [ StringBuilder: "" ]  (খালি)
✔ বৈধ — final থাকা অবস্থায়ও পুরো লেখা মুছে ফেলা গেল

একই কথা collection-এর ক্ষেত্রে, আর এখানেই বাস্তব bug জন্মায়:

static final List<String> HOLIDAYS = new ArrayList<>();
HOLIDAYS.add("21 February");          // চলে — final হলেও
HOLIDAYS.clear();                     // এটাও চলে!

static final List<String> FIXED = List.of("21 February", "26 March");
FIXED.add("16 December");             // চলার সময় UnsupportedOperationException

প্রথম HOLIDAYS নাম দেখে constant মনে হয়, কিন্তু যেকোনো কোড তাতে যোগ বা মুছে ফেলতে পারে। সত্যিই না-বদলানো তালিকা চাইলে List.of(…) বা List.copyOf(…) দিন — এগুলো unmodifiable list ফেরত দেয়, যাতে add করলে exception আসে (পর্ব ৩০)। মনে রাখুন: immutable হওয়া object-এর নিজের গুণ, ভ্যারিয়েবলের final থেকে সেটা আসে না। String, Integer, LocalDate immutable — final ছাড়াও; StringBuilder, ArrayList mutable — final দিয়েও।

Effectively final — final না লিখেও final

Java 8 থেকে একটি নতুন ধারণা যোগ হয়েছে: যে local variable-এ ঘোষণার পর আর কখনো নতুন মান বসানো হয় না, সেটা final না লিখলেও effectively final. এর গুরুত্ব আসে lambda-তে (পর্ব ৩৪): lambda বা anonymous class বাইরের যে local variable ব্যবহার করে, সেটা final বা effectively final হতেই হবে।

int count = 0;
count++;                                  // count আর effectively final নয়
Supplier<Integer> s = () -> count;        // ✗

Main.java:10: error: local variables referenced from a lambda expression must be final or effectively final
        Supplier<Integer> s = () -> count;
                                    ^

কেন এই নিয়ম? Lambda পরে, এমনকি অন্য thread-এ চলতে পারে, যখন method-এর local variable-এর frame আর নেই। তাই Java মানটির একটি কপি lambda-র সাথে রেখে দেয়। ভ্যারিয়েবল বদলাতে থাকলে “কোন মানের কপি?” প্রশ্নে বিভ্রান্তি হতো — Java সেই সম্ভাবনাটাই বন্ধ করেছে। বিস্তারিত পর্ব ৩৪-এ।

৭ · final method, final class আর immutable class-এর রেসিপি

Method-এর আগে final লিখলে subclass সেই method নতুন করে লিখতে (override করতে) পারে না। Class-এর আগে লিখলে কেউ সেই class থেকে subclass বানাতেই পারে না — এটা final class. পরের পর্বে inheritance শেখার পর এর পূর্ণ অর্থ বুঝবেন; আপাতত একটি পরিচিত উদাহরণ — String নিজেই final:

error: cannot inherit from final String
class MyText extends String { }
                     ^

কেন একটি class-কে বন্ধ করে দেওয়া? কারণ subclass চাইলে method override করে আচরণ বদলে দিতে পারত — একটি “String” যার মান হঠাৎ বদলায়, তা পুরো Java জগতের নিরাপত্তা ভেঙে দিত (ভাবনার প্রশ্ন ৪)। final method একই কাজ করে ছোট পরিসরে: class খোলা থাকে, কিন্তু নির্দিষ্ট কিছু method-এর আচরণ সবার জন্য স্থির। বিস্তারিত পর্ব ১৯-তে।

Immutable class বানানোর রেসিপি

টাকার হিসাবের জন্য একটি Taka class ভাবুন। ব্যাংক ব্যালান্স, বিল, VAT — এই মানগুলো যদি কোথাও গোপনে বদলে যায়, বিপদ। সমাধান: একবার তৈরি হলে যে object আর বদলায় না। Joshua Bloch-এর Effective Java বইয়ের নিয়মগুলোর ভিত্তিতে একটি immutable class-এর রেসিপি পাঁচ ধাপে সাজানো যায়:

1. সব field private final — বাইরে থেকে ছোঁয়া যাবে না, ভেতর থেকেও দ্বিতীয়বার বসানো যাবে না।
2. কোনো setter নেই — অবস্থা বদলানোর কোনো method নেই। “বদলানো” মানে নতুন object ফেরত দেওয়া, যেমন plus.
3. Class final — যাতে কোনো subclass mutable আচরণ ঢোকাতে না পারে।
4. Defensive copy — field-এ কোনো mutable object (List, array, Date) থাকলে constructor-এ তার কপি রাখুন, আর getter-এ ভেতরেরটা না দিয়ে কপি বা unmodifiable view দিন।
5. constructor-এ this বাইরে ফাঁস করবেন না — পুরোপুরি তৈরি হওয়ার আগে অন্য কেউ object দেখে ফেললে নিশ্চয়তা ভাঙে।

final class TaxCalculator {
    static final double VAT_RATE = 0.15;
    private TaxCalculator() { }          // object বানানো নিষেধ
    static long vatOf(long paisa) { return Math.round(paisa * VAT_RATE); }
}

final class Taka {
    private final long paisa;
    Taka(long paisa) { this.paisa = paisa; }
    Taka plus(Taka other) { return new Taka(paisa + other.paisa); }
    Taka withVat() { return new Taka(paisa + TaxCalculator.vatOf(paisa)); }
    @Override public String toString() { return String.format("%d.%02d tk", paisa / 100, paisa % 100); }
}

class Main {
    public static void main(String[] args) {
        Taka tea = new Taka(2500), cake = new Taka(3500);
        Taka bill = tea.plus(cake);
        System.out.println("bill = " + bill + ", VAT soho = " + bill.withVat());
        System.out.println("tea ekhono = " + tea);
        final StringBuilder log = new StringBuilder("log");
        log.append(" | ").append(bill);   // final, তবু ভেতরটা বদলায়
        System.out.println(log);
    }
}

Immutable object-এর লাভ বড়। (১) Thread safety: যে object বদলায়ই না, তাকে একশো thread একসাথে পড়লেও কোনো গোলমাল নেই — কোনো lock লাগে না (thread-safe). (২) নির্ভয়ে ভাগ করা: একটি Taka দশটি object-এর সাথে ভাগ করলেও কেউ অন্যের হিসাব নষ্ট করতে পারবে না; পর্ব ১২-এর aliasing-এর ভয় থাকে না। (৩) সহজ যুক্তি: একবার ঠিকঠাক তৈরি হলে চিরকাল ঠিক। খরচ একটাই — প্রতিটি “বদলে” নতুন object, যা সাধারণত নগণ্য। Java 16 থেকে এমন ডেটা-class অনেক সংক্ষেপে লেখা যায় record দিয়ে — পর্ব ২৫-এ দেখবেন, record Taka(long paisa) { } লিখলেই প্রথম দুটি ধাপ আর class-এর final হওয়া নিজে থেকে হয়ে যায়।

৮ · static-এর ফাঁদ — global state, টেস্ট আর memory leak

static field সুবিধাজনক: যেকোনো জায়গা থেকে ClassName.field লিখলেই পাওয়া যায়, কোনো object পাস করতে হয় না। ঠিক এই সুবিধাই তাকে বিপজ্জনক করে। static final constant নিরাপদ — সে বদলায় না। সমস্যা হলো বদলানো যায় এমন static field, যা কার্যত একটি global state.

Java-তে “মেমরি তো GC সামলায়” — তবু leak হয় কীভাবে? Leak মানে এখানে মেমরি হারানো নয়, বরং অপ্রয়োজনীয় object-কে ভুল করে ধরে রাখা। একটি static map-এ প্রতিটি request-এর তথ্য রাখলেন, মুছলেন না — GC দেখে কেউ এখনো সেগুলোর দিকে তাকিয়ে আছে, তাই সরায় না। একে বলে memory leak, আর Java সার্ভারে এর সবচেয়ে প্রচলিত উৎস এই ধরনের static collection.

Singleton — একটিমাত্র object-এর ধারণা

কখনো কখনো একটি class-এর পুরো প্রোগ্রামে ঠিক একটি object থাকা দরকার — যেমন একটি কনফিগারেশন বা একটি লগার। এই নকশার নাম Singleton, আর এটা static দিয়েই তৈরি হয়:

final class AppConfig {
    private static final AppConfig INSTANCE = new AppConfig();
    private AppConfig() { }                       // বাইরে থেকে new নিষেধ
    static AppConfig getInstance() { return INSTANCE; }
}

Singleton খুব জনপ্রিয়, আবার খুব সমালোচিতও — কারণ ভেতরে ভেতরে এটা একটি global state, আর ওপরের চারটি সমস্যার অনেকগুলো নিয়ে আসে। ভাবনার প্রশ্ন ৫-এ এই বিতর্ক আর enum দিয়ে singleton বানানোর কৌশল দেখবেন; design pattern হিসেবে পূর্ণ আলোচনা পর্ব ৪৮-এ। আপাতত নিয়ম: static রাখুন constant আর অবস্থাহীন (stateless) utility method-এর জন্য; বদলানো অবস্থা রাখুন object-এর ভেতরে।

৯ · AI-এর যুগে — static দিয়ে error চাপা দেওয়া ধরুন

“non-static variable cannot be referenced from a static context” — এই error AI-কে দেখালে সবচেয়ে সহজ যে সমাধান সে দেয়: সংশ্লিষ্ট field আর method-এর আগে static বসিয়ে দেওয়া। Error চলে যায়, প্রোগ্রাম চলে। কিন্তু এখন প্রতিটি Student-এর আলাদা নাম নেই — সবার নাম একটিই, শেষে যেটা বসানো হয়েছে। Compile error সরে গিয়ে এসেছে একটি নীরব logic bug, যা অনেক বেশি বিপজ্জনক।

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

• প্রতিটি static field-এর জন্য বলতে পারি “এটা পুরো class-এর, কোনো একটি object-এর নয়”
• বদলানো যায় এমন static field নেই, থাকলে private আর তার যৌক্তিক কারণ আছে
• constant-গুলো static final, নাম UPPER_SNAKE_CASE, আর সত্যিই কখনো বদলায় না
• final field-এ mutable object থাকলে তা বাইরে থেকে বদলানো যায় কি না পরীক্ষা করেছি
• দুটি object বানিয়ে দেখেছি — একটির instance field বদলালে অন্যটি অপরিবর্তিত থাকে
• কোনো static collection থাকলে তার আকার সীমিত, বা মোছার নিয়ম আছে