Encapsulation আর access modifier — object নিজের ডেটা নিজে পাহারা দেয়

১ · Encapsulation — object নিজের ডেটা নিজে পাহারা দেয়

পর্ব ১৫-এ class দিয়ে নিজের টাইপ বানিয়েছেন, পর্ব ১৬-এ constructor দিয়ে object-কে শুরু থেকেই ঠিক অবস্থায় তৈরি করেছেন। কিন্তু তৈরি হওয়ার পরে কী হবে? ধরুন একটি মোবাইল ওয়ালেটের Account class-এ balance নামে একটি field আছে। প্রোগ্রামের যেকোনো জায়গা থেকে যদি acc.balance = -5000; লেখা যায়, তাহলে constructor যত যত্ন করেই লেখা হোক, এক লাইনেই সব নিয়ম ভেঙে যায়।

পর্ব ০২-এ একটি শব্দ শিখেছিলেন: invariant — এমন নিয়ম যা একটি object-এর জন্য সবসময় সত্য থাকতে হবে। ওয়ালেটের invariant হতে পারে: “ব্যালান্স কখনো শূন্যের নিচে নামবে না” আর “এক দিনে ২৫,০০০ টাকার বেশি তোলা যাবে না।” প্রশ্ন হলো, এই নিয়ম কে রক্ষা করবে? উত্তরটাই এই পর্বের মূল কথা: object নিজেই।

Encapsulation শব্দের দুটি অংশ আছে। প্রথমত, ডেটা আর সেই ডেটার নিয়ম একই class-এ থাকে — ব্যালান্স আর “ব্যালান্স কীভাবে কমবে” একসাথে। দ্বিতীয়ত, বাইরের কোড ডেটা সরাসরি ছুঁতে পারে না; শুধু class-এর দেওয়া method দিয়ে অনুরোধ করতে পারে। দ্বিতীয় অংশটির আরেকটি নাম আছে — information hiding: class-এর ভেতরে কী আছে আর কীভাবে আছে, তা বাইরের কাউকে জানতে হবে না।

Java-তে এই পাহারার যন্ত্র হলো access modifier — private, protected, public, অথবা কিছু না লেখা। এরা compiler-কে বলে কোন নাম কোথা থেকে ব্যবহার করা যাবে। নিয়ম ভাঙলে প্রোগ্রাম চলার সময় নয়, compile-এর সময়েই আটকে যায়। অর্থাৎ ভুলটা কোনো গ্রাহকের টাকায় পৌঁছানোর অনেক আগে ধরা পড়ে।

২ · Public field-এর বিপদ, আর private-এর সমাধান

একটি বড় অ্যাপে হাজারো লাইন কোড, দশজন প্রোগ্রামার। balance যদি public হয়, তাহলে যে কেউ যেকোনো জায়গা থেকে তাতে হাত দিতে পারে — রিপোর্টের স্ক্রিন, রিফান্ডের কোড, কোনো জরুরি bug fix. নিচের ডায়াগ্রামে দুটি নকশা পাশাপাশি দেখুন। “পরে” চাপুন:

class Account {
    public long balance;      // সবার জন্য খোলা
}

acc.balance = 1000;
ব্যালান্স: 1000 টাকা — এখনো সব ঠিক

// RefundScreen.java — তাড়াহুড়োয় লেখা
acc.balance = acc.balance - 6000;

ব্যালান্স: -5000 টাকা
compiler চুপ, প্রোগ্রাম চুপ — কেউ থামায়নি

$ grep -rn "balance =" src/
ReportScreen.java:88     acc.balance = ...
RefundScreen.java:41     acc.balance = ...
AdminTool.java:203       acc.balance = ...
... আরও ৩৭টি জায়গা
নিয়মটা কোথায় লেখা? কোথাও না — বা ৪০ জায়গায় ৪০ রকম

class Account {
    private long balance;
    String withdraw(long amount) {
        if (amount > balance) return "REJECTED";
        balance -= amount; return "OK";
    }
}
acc.withdraw(6000);   →  "REJECTED"
ব্যালান্স: 1000 টাকাই থাকল

acc.balance = -5000;

error: balance has private access in Account
প্রোগ্রাম তৈরিই হলো না — ভুল গ্রাহক পর্যন্ত পৌঁছাল না

এবার একটি পূর্ণ ওয়ালেট class. এতে দুটি নিয়ম আছে — ব্যালান্সের বেশি তোলা যাবে না, আর দিনে ২৫,০০০ টাকার বেশি তোলা যাবে না। চালিয়ে দেখুন কোন অনুরোধ পাস হয় আর কোনটি নাকচ হয়:

class Wallet {
    private static final long DAILY_LIMIT = 25_000;   // static final: পর্ব ১৮
    private long balance;
    private long withdrawnToday;
    Wallet(long openingBalance) { balance = openingBalance; }
    String withdraw(long amount) {
        if (amount <= 0)                           return "REJECTED: invalid amount";
        if (amount > balance)                      return "REJECTED: not enough balance";
        if (withdrawnToday + amount > DAILY_LIMIT) return "REJECTED: daily limit";
        balance -= amount;
        withdrawnToday += amount;
        return "OK, balance " + balance;
    }
    long getBalance() { return balance; }
}

class Main {
    public static void main(String[] args) {
        Wallet w = new Wallet(30_000);
        long[] tries = {5_000, -200, 40_000, 22_000, 20_000};
        for (long t : tries) System.out.println(t + " -> " + w.withdraw(t));
        System.out.println("Final: " + w.getBalance());
        // w.balance = -5000;   // এই লাইন চালু করলে compile error
    }
}

একটি জিনিস লক্ষ করুন: Main আর Wallet একই ফাইলে, একই package-এ আছে। তবুও Main থেকে balance দেখা যায় না, কারণ private মানে “শুধু এই class-এর ভেতরে” — একই ফাইল বা একই package-এ থাকলেও না। অনলাইন runner-এ সব class একটি ফাইলে, একটি package-এ থাকে; তাই এখানে আপনি যে access level-টি সত্যিই পরীক্ষা করতে পারবেন, সেটি হলো private. বাকি তিনটির আচরণ পরের অংশে compiler-এর আসল মেসেজ দিয়ে দেখাচ্ছি।

৩ · চারটি access level — কে কোথা থেকে দেখতে পায়

Java-তে একটি field, method বা constructor-এর সামনে চারটির যেকোনো একটি access level বসে। কিছু না লিখলেও একটি level থাকে — তার নাম package-private (অনেকে বলেন “default access”). সবচেয়ে কড়া থেকে সবচেয়ে খোলা পর্যন্ত:

দুটি জিনিস প্রায়ই ভুল বোঝা হয়। প্রথমত, protected package-private-এর চেয়ে বেশি খোলা, কম নয় — একই package-এর সবাই তো পায়ই, সাথে অন্য package-এর subclass-ও পায়। দ্বিতীয়ত, public class-এর ভেতরের member দেখতে হলে class-টিও দেখা যেতে হবে; package-private class-এর public method অন্য package থেকে কাজে আসে না। Subclass আর protected-এর পুরো গল্প (বিশেষ করে অন্য package থেকে কোন reference দিয়ে ঢোকা যায়) আসবে পর্ব ১৯-এ inheritance শেখার সময়।

নিচের ডায়াগ্রামে একটিই Wallet class, চারটি field, চারটি access level. চারটি ভিন্ন জায়গা থেকে এগুলো ছোঁয়ার চেষ্টা করা হচ্ছে। প্রতিটি ধাপে কোন লাইন হাইলাইট হয়েছে (মানে সেখান থেকে দেখা যায়), আর compiler কী বলছে, দেখুন:

1package com.abcltech.bank;2public class Wallet {3    private   long balance;4              long dailyLimit;5    protected long fee;6    public    String owner;7}

Private মানে “এই class-এর”, “এই object-এর” নয়

ইন্টারভিউর একটি প্রিয় প্রশ্ন: একটি Wallet object কি আরেকটি Wallet object-এর private field পড়তে পারে? উত্তর — হ্যাঁ। Java-র access নিয়ম class ধরে কাজ করে, object ধরে নয়। নিচের transferTo method নিজের balance-এর সাথে other.balance-ও বদলায়, আর এটা বৈধ:

class Wallet {
    private long balance;
    boolean transferTo(Wallet other, long amount) {
        if (amount <= 0 || amount > balance) return false;
        balance -= amount;
        other.balance += amount;      // বৈধ: একই class-এর ভেতরের কোড
        return true;
    }
}

কারণটা যুক্তিসঙ্গত: Wallet class-এর কোড যিনি লিখছেন, তিনি দুটি object-এরই নিয়ম জানেন। পাহারা দরকার অন্য class-এর কোড থেকে।

Top-level class-এর জন্য মাত্র দুটি পছন্দ

একটি ফাইলের সরাসরি ভেতরের (top-level) class হয় public, নয়তো কিছু না লেখা (package-private). private class Wallet বা protected class Wallet top-level-এ লেখা যায় না — modifier private not allowed here error আসে। একটি ফাইলে বড়জোর একটি public top-level class থাকতে পারে, আর তার নাম ফাইলের নামের সাথে হুবহু মিলতে হয় (public class Wallet থাকবে Wallet.java-তে)। এজন্যই এই কোর্সের runnable কোডে Main class-এর সামনে public নেই — অনলাইন runner ফাইলটিকে অন্য নামে compile করে। নিজের প্রজেক্টে সাধারণত public class Main থাকে Main.java-তে। Class-এর ভেতরের (nested) class private হতে পারে — পর্ব ২৭-এ দেখবেন।

৪ · Package — নাম, ফোল্ডার আর import

package-private আর protected বুঝতে হলে package বুঝতে হবে। Package হলো সম্পর্কিত class-গুলোর একটি নামযুক্ত দল। Java-র নিজের library-ও package-এ সাজানো: java.util-এ collection, java.time-এ তারিখ-সময়, java.io-তে ফাইল। Package দুটি কাজ করে: নামের সংঘর্ষ ঠেকায় (দুটি কোম্পানির দুটি Wallet class আলাদা package-এ নিশ্চিন্তে থাকতে পারে), আর encapsulation-এর একটি স্তর তৈরি করে — package-এর ভেতরের সাহায্যকারী class-গুলো বাইরে লুকিয়ে রাখা যায়।

package statement আর ফোল্ডার

একটি ফাইল কোন package-এর, তা লেখা হয় ফাইলের একদম প্রথম statement-এ: package com.abcltech.bank;. নামের রীতি হলো কোম্পানির ডোমেইন উল্টো করে লেখা — abcltech.com থেকে com.abcltech, তারপর প্রজেক্টের অংশ। এতে সারা পৃথিবীতে package-এর নাম আলাদা থাকে। সব অক্ষর ছোট হাতের। আর package-এর নাম মেলে ফোল্ডারের সাথে:

src/
└── com/
    └── abcltech/
        ├── bank/
        │   ├── Wallet.java          (package com.abcltech.bank;)
        │   └── WalletService.java   (package com.abcltech.bank;)
        └── app/
            └── Main.java            (package com.abcltech.app;)

package লাইন না লিখলে class যায় একটি নামহীন package-এ (unnamed package). ছোট পরীক্ষার জন্য চলে, কিন্তু অন্য কোনো package থেকে সেই class import করাই যায় না — তাই আসল প্রজেক্টে সবসময় package থাকে। Maven বা Gradle প্রজেক্টে (পর্ব ৪৬) এই কাঠামো থাকে src/main/java/-এর নিচে।

Fully qualified name আর import

Package-সহ একটি class-এর পুরো নামকে বলে fully qualified name: com.abcltech.bank.Wallet, java.util.Scanner, java.time.LocalDate. JVM-এর কাছে এটাই class-এর আসল নাম। প্রতিবার পুরো নাম লেখা ক্লান্তিকর, তাই আছে import:

package com.abcltech.app;

import com.abcltech.bank.Wallet;    // শুধু এই class
import java.util.*;                 // java.util-এর সব public class (sub-package নয়)

public class Main {
    public static void main(String[] args) {
        Wallet w = new Wallet(1000);                   // import থাকায় ছোট নাম
        java.time.LocalDate d = java.time.LocalDate.of(2026, 10, 18); // import ছাড়া পুরো নাম
        List<String> names = new ArrayList<>();       // java.util.* থেকে
    }
}

তিনটি জিনিস মনে রাখুন। (১) import কোনো কোড কপি করে না, কিছু লোডও করে না — শুধু compiler-কে বলে “Wallet লিখলে com.abcltech.bank.Wallet বুঝবে।” C-র #include-এর সাথে এর কোনো মিল নেই। (২) java.lang package (String, Math, System) সবসময় নিজে থেকেই import করা থাকে। (৩) java.util.* শুধু ওই package-এর class আনে, java.util.function-এর মতো sub-package নয় — Java-তে “sub-package” আসলে সম্পূর্ণ আলাদা package, নামের মিলটা শুধু গোছানোর জন্য। এর মানে com.abcltech.bank.internal-এর class com.abcltech.bank-এর package-private জিনিস দেখতে পায় না।

একই সরল নামের দুটি class লাগলে একটি import করুন, অন্যটি পুরো নামে লিখুন — যেমন java.util.Date আর java.sql.Date. দুটিকে নাম ধরে import করলে দ্বিতীয় import লাইনেই error আসে: a type with the same simple name is already defined by the single-type-import of Date. আর java.util.* ও java.sql.* দুটিই import করে শুধু Date লিখলে compiler বলে reference to Date is ambiguous.

Package-এর বাইরে থেকে ঢোকার চেষ্টা — compiler যা বলে

ওপরের ফোল্ডার কাঠামোয় ধরুন Wallet-এ একটি package-private method void audit() আছে, আর WalletService class-টির সামনে public লেখা নেই। com.abcltech.app.Main থেকে এগুলো ব্যবহার করতে গেলে javac এই ধরনের মেসেজ দেয়:

Main.java:4: error: WalletService is not public in com.abcltech.bank; cannot be accessed from outside package
import com.abcltech.bank.WalletService;
                        ^
Main.java:9: error: audit() is not public in Wallet; cannot be accessed from outside package
        w.audit();
         ^

মেসেজ পড়ার কৌশল: has private access মানে member-টি private; has protected access মানে protected; is not public ... outside package মানে সামনে কিছু লেখা নেই (package-private). সবগুলো মেসেজ OpenJDK 21-এ একাধিক package-এর ফাইল compile করে যাচাই করা। এই তিনটি চিনলেই access-সংক্রান্ত প্রায় সব compile error নিজে ঠিক করতে পারবেন।

৫ · Getter আর setter — কখন কাজের, কখন শুধু আনুষ্ঠানিকতা

Field private করলে বাইরের কোড পড়বে কীভাবে? প্রচলিত উত্তর: getter আর setter. Getter একটি মান ফেরত দেয় (getBalance()), setter একটি মান বসায় (setBalance(long)). কিন্তু সাবধান: প্রতিটি field-এর জন্য একটি getter আর একটি setter লিখে দিলে আপনি আসলে public field-ই বানালেন, শুধু লম্বা পথে। setBalance(-5000) আর balance = -5000-এর মধ্যে কোনো পার্থক্য নেই, যদি setter কিছুই যাচাই না করে।

Getter-setter সত্যিই কাজে আসে তিনটি ক্ষেত্রে:

class Student {
    private double gpa;
    void setGpa(double gpa) {
        if (gpa < 0.0 || gpa > 5.0)
            throw new IllegalArgumentException("GPA must be 0.0-5.0: " + gpa);
        this.gpa = gpa;
    }
    double getGpa() { return gpa; }
}

class Temperature {
    private final double celsius;                  // তৈরির পরে বদলায় না
    Temperature(double celsius) { this.celsius = celsius; }
    double getCelsius()    { return celsius; }
    double getFahrenheit() { return celsius * 9 / 5 + 32; }   // field নেই, হিসাব
}

Temperature-এ getFahrenheit() দেখে বাইরের কেউ বুঝতে পারে না ভেতরে ফারেনহাইট রাখা আছে নাকি হিসাব হচ্ছে — আর বোঝার দরকারও নেই। কাল যদি আপনি ভেতরে কেলভিনে রাখার সিদ্ধান্ত নেন, শুধু এই class বদলাবে; যারা getFahrenheit() ডাকে, তাদের একটি লাইনও বদলাতে হবে না। Public field থাকলে সেটা অসম্ভব হতো — এটাই information hiding-এর আসল লাভ। (IllegalArgumentException ছোড়া মানে ভুল মান সরাসরি প্রত্যাখ্যান করা; exception-এর বিস্তারিত পর্ব ২৯-এ।)

যখন getter-setter শুধু আনুষ্ঠানিকতা

পর্ব ০২-এ anemic class-এর কথা বলেছিলাম — যে class শুধু ডেটা আর getter-setter রাখে, আর সব নিয়ম লেখা থাকে অন্য কোথাও। এমন class-এ private লেখা থাকলেও encapsulation নেই, কারণ নিয়মের পাহারাদার class নিজে নয়। দেখার সহজ পরীক্ষা: কোনো setter কি কখনো “না” বলে? কোনো field কি এমন আছে যা বাইরে থেকে বদলানোই উচিত নয় (id, তৈরির তারিখ, ব্যালান্স), অথচ তার setter আছে? থাকলে নকশাটি নিয়ে আবার ভাবুন।

আবার উল্টোটাও সত্য: কিছু class-এর কাজই শুধু ডেটা বহন করা — যেমন API-তে পাঠানোর একটি ফর্মের তথ্য। এমন ক্ষেত্রে হাতে লেখা getter-setter-এর বদলে Java 16 থেকে আছে record (পর্ব ২৫), যা এক লাইনে immutable ডেটা-class বানায়। নিয়ম-ওয়ালা object আর শুধু-ডেটা object — দুটিকে আলাদা করে চেনাই আসল দক্ষতা।

JavaBeans-এর নাম রাখার রীতি — কেন getX, isX, setX

নামগুলো এলোমেলো নয়। ১৯৯০-এর দশকের শেষে Sun Microsystems JavaBeans নামে একটি নির্দেশিকা দেয়: একটি “bean” class-এ একটি খালি constructor থাকবে, আর প্রতিটি property-র জন্য getName() / setName(...); boolean property-র ক্ষেত্রে getter হতে পারে isActive(). এর উদ্দেশ্য ছিল টুলগুলো যেন method-এর নাম দেখে নিজে থেকে property খুঁজে নিতে পারে।

আজও বহু framework এই রীতির ওপর দাঁড়িয়ে। JSON লাইব্রেরি Jackson একটি object-কে JSON বানানোর সময় সাধারণত getName() দেখে "name" নামের ঘর বানায়; Spring ফর্ম বা configuration থেকে মান বসানোর সময় setName খোঁজে। তাই getname() বা fetchName() লিখলে কোড compile হবে, কিন্তু framework হয়তো property-টি দেখতেই পাবে না — নীরব bug. (নতুন সংস্করণের Jackson record-ও সরাসরি বোঝে।) এই লাইব্রেরিগুলো অনলাইন runner-এ নেই, তাই নিচের কোড শুধু দেখার জন্য:

public class Customer {
    private String name;
    private boolean active;
    public Customer() {}                              // খালি constructor
    public String getName()          { return name; }
    public void setName(String name) { this.name = name; }
    public boolean isActive()        { return active; } // boolean-এ isX
    public void setActive(boolean a) { this.active = a; }
}
// Jackson দিয়ে JSON বানালে (প্রত্যাশিত): {"name":"Rahim","active":true}

৬ · Tell, Don't Ask — জিজ্ঞেস না করে কাজটা করতে বলুন

Getter-setter-এর নেশা কাটানোর সবচেয়ে কাজের নীতিটির নাম Tell, Don't Ask. দুটি কোড তুলনা করুন:

// ডাকার জায়গায় নিয়ম — প্রতিটি caller-কে মনে রাখতে হবে
if (acc.getBalance() >= 500) {
    acc.setBalance(acc.getBalance() - 500);
}

// নিয়ম object-এর ভেতরে — caller শুধু চায়
acc.withdraw(500);

প্রথম সংস্করণে নিয়মটি (“যথেষ্ট টাকা থাকলে তবেই”) লেখা হয়েছে ডাকার জায়গায়। দশ জায়গা থেকে টাকা তোলা হলে নিয়মটি দশবার লিখতে হবে, আর একবার ভুলে গেলেই ব্যালান্স ঋণাত্মক। দৈনিক সীমা যোগ করতে হলে দশ জায়গায় যেতে হবে। দ্বিতীয় সংস্করণে caller শুধু বলে “৫০০ টাকা তোলো” — কীভাবে, কোন নিয়মে, তা Account-এর দায়িত্ব। পর্ব ০২-এর ভাষায়: object-কে বার্তা পাঠান, তার পেট থেকে ডেটা বের করে নিজে কাজ করবেন না।

তবে এটি অন্ধ নিয়ম নয়। রিপোর্ট দেখানো, স্ক্রিনে ব্যালান্স ছাপা, JSON বানানো — এসব কাজে পড়ার জন্য getter স্বাভাবিক। সমস্যা হয় যখন caller getter দিয়ে ডেটা বের করে, সিদ্ধান্ত নেয়, তারপর setter দিয়ে ফেরত বসায়। সিদ্ধান্ত যেখানে, নিয়মও সেখানে থাকা উচিত।

৭ · ভেতরের ডেটা যেন ফাঁস না হয় — defensive copy

এবার এমন একটি ফাঁক, যা অভিজ্ঞ প্রোগ্রামারও প্রায়ই রেখে দেন। পর্ব ১২-১৩-এ দেখেছেন: array একটি object, ভ্যারিয়েবলে থাকে তার reference. ধরুন Student-এর ভেতরে private int[] marks আছে। Field private, কিন্তু getter যদি return marks; করে, তাহলে caller পায় একই array-র reference — আর marks[0] = 100 লিখে ভেতরের নম্বর বদলে ফেলতে পারে। দরজায় তালা, কিন্তু চাবির কপি সবার হাতে। একই কাণ্ড ঘটে উল্টো দিকেও: constructor যদি বাইরে থেকে আসা array সরাসরি রেখে দেয়, তাহলে যে array পাঠিয়েছে সে পরে সেটা বদলালে object-ও বদলে যায়। দুটি reference একই object দেখার এই অবস্থাকে বলে aliasing.

সমাধানের নাম defensive copy: mutable কিছু ঢোকার সময় কপি রাখুন, বের হওয়ার সময় কপি দিন। ডায়াগ্রামে stack আর heap-এ কী ঘটে দেখুন:

stack                          heap
main:     input ──────┐
                      ├──▶ [ 70, 80, 90 ]
Student:  marks ──────┘
দুটি reference, একটিই array

stack                          heap
main:     input ──────┐
                      ├──▶ [ 0, 80, 90 ]
Student:  marks ──────┘
Student-কে কেউ ছোঁয়নি, তবু তার নম্বর বদলে গেল

stack                          heap
main:     input ─────────▶ [ 0, 80, 90 ]   (বাইরের)
Student:  marks ─────────▶ [ 70, 80, 90 ] (নিজের কপি)
input বদলালেও Student-এর কপি অক্ষত

stack                          heap
Student:  marks ──────┐
                      ├──▶ [ 70, 80, 0 ]
main:     leak  ──────┘
leak[2] = 0;
getter ভেতরের array-ই দিয়ে দিয়েছে — বাইরে থেকে বদল

stack                          heap
Student:  marks ─────────▶ [ 70, 80, 90 ]
main:     copy  ─────────▶ [ 70, 0, 90 ]
copy[1] = 0;
caller তার নিজের কপি বদলাল — Student টের পেল না

এবার নিজে চালিয়ে দেখুন। এই Student-এর constructor কপি রাখে, getMarks() কপি দেয়, কিন্তু ইচ্ছা করে একটি ভুল getter getMarksLeaky()-ও রাখা হয়েছে:

import java.util.Arrays;
class Student {
    private final String name;
    private final int[] marks;
    Student(String name, int[] marks) {
        this.name = name;
        this.marks = marks.clone();                 // ঢোকার পথে কপি
    }
    int[] getMarksLeaky() { return marks; }         // ভুল: ভেতরের array-ই দিল
    int[] getMarks()      { return marks.clone(); } // ঠিক: কপি দিল
    String report() { return name + " " + Arrays.toString(marks); }
}

class Main {
    public static void main(String[] args) {
        int[] input = {70, 80, 90};
        Student s = new Student("Nadia", input);
        input[0] = 0;
        System.out.println("1: " + s.report());
        s.getMarks()[1] = 0;
        System.out.println("2: " + s.report());
        s.getMarksLeaky()[2] = 0;
        System.out.println("3: " + s.report());
    }
}

List হলে কী করবেন, আর immutability-র দিকে এক পা

List শিখবেন পর্ব ৩০-এ, কিন্তু নিয়মটি একই। ভেতরের ArrayList সরাসরি ফেরত দিলে caller add বা clear করে ফেলতে পারে। নিরাপদ উপায় হলো List.copyOf(items) ফেরত দেওয়া (Java 10 থেকে আছে) — এটি একটি অপরিবর্তনীয় কপি, যাতে add করলে UnsupportedOperationException আসে। List.of(...)-ও একইভাবে অপরিবর্তনীয় list বানায়। খেয়াল রাখবেন, clone() বা copyOf হলো shallow copy — ভেতরের element-গুলো নিজেরা mutable object হলে সেগুলো কপি হয় না।

সবচেয়ে সহজ পাহারা হলো এমন object, যা বদলানোই যায় না: সব field private final, কোনো setter নেই, mutable field থাকলে ঢোকা-বেরোনোর পথে কপি। এমন object-কে বলে immutable — String এর সবচেয়ে পরিচিত উদাহরণ (পর্ব ০৮)। ওপরের Temperature ইতিমধ্যে immutable. Immutable object-এর invariant একবার constructor-এ যাচাই করলেই চিরকাল সত্য, আর একাধিক thread একসাথে নিরাপদে পড়তে পারে। final-এর পুরো ব্যবহার আসবে পরের পর্বে, আর immutable ডেটার সবচেয়ে সংক্ষিপ্ত রূপ record পর্ব ২৫-এ।

৮ · ওপরের আর নিচের স্তর — module আর reflection

Module — package-এর ওপরে আরেকটি দেয়াল

Package-এর একটি দুর্বলতা আছে। ধরুন আপনার লাইব্রেরিতে দুটি package: com.abcltech.bank (ব্যবহারকারীদের জন্য) আর com.abcltech.bank.internal (শুধু নিজের কাজে)। internal-এর class-গুলো bank থেকে ব্যবহার করতে হলে তাদের public করতে হয় — কারণ দুটি আলাদা package. কিন্তু public করা মানে সারা পৃথিবীর জন্য খোলা। Java 9 (২০১৭) এই সমস্যার সমাধানে আনে module system (JPMS, Project Jigsaw). একটি module-এর মূলে থাকে module-info.java ফাইল:

module com.abcltech.bank {
    exports com.abcltech.bank;        // শুধু এই package বাইরে দেখা যাবে
    requires java.sql;                // এই module-এর ওপর নির্ভর করি
    // com.abcltech.bank.internal export করা হয়নি:
    // সেখানকার public class-ও অন্য module থেকে অদৃশ্য
}

অর্থাৎ module-এ এসে public-এর মানে দাঁড়ায় “export করা package-এর ভেতরে public.” JDK নিজেই কয়েক ডজন module-এ ভাগ করা (java.base, java.sql…), আর তার ভেতরের sun.* ধরনের অভ্যন্তরীণ package এখন বাইরে বন্ধ (ভাবনার প্রশ্ন ৩)। ছোট প্রজেক্ট আর বেশিরভাগ Spring Boot অ্যাপ module ছাড়াই চলে — তখন সব কোড থাকে একটি “unnamed module”-এ। আপাতত এটুকু জানাই যথেষ্ট যে encapsulation-এর সিঁড়িটা এরকম: private → package → module.

Reflection — private-এর তালাও খোলা যায়

Java-তে চলার সময় একটি class-এর field, method খুঁজে বের করে ব্যবহার করার একটি API আছে — reflection (পর্ব ৪৫)। এটি দিয়ে private field-ও পড়া-লেখা যায়:

Field f = Wallet.class.getDeclaredField("balance");   // java.lang.reflect.Field
f.setAccessible(true);                                 // private-এর তালা খোলা
f.setLong(w, -5000);                                   // invariant ভাঙা হলো
System.out.println(w.getBalance());                    // -5000

এজন্য মনে রাখবেন: private নিরাপত্তা-ব্যবস্থা নয়, নকশার চুক্তি। এটি ভুল আর অসাবধানতা ঠেকায়, ইচ্ছাকৃত আক্রমণ নয়। Framework-গুলো (JPA, কিছু ক্ষেত্রে Jackson, test টুল) ঠিক এই পথে private field-এ মান বসায়। Module system এখানেও দেয়াল তোলে: অন্য module-এর যে package opens করা হয়নি, তার ভেতরে setAccessible(true) করলে InaccessibleObjectException আসে। পাসওয়ার্ড বা গোপন key রক্ষা করতে হয় অন্য উপায়ে — encryption, আলাদা প্রক্রিয়া, সার্ভারের অনুমতি-ব্যবস্থা।

৯ · AI-এর যুগে — কোন setter থাকা উচিতই নয়, তা জানা আপনার কাজ

AI-কে “একটি BankAccount class লিখে দাও” বললে প্রায় নিশ্চিতভাবে পাবেন: সব field private, আর প্রতিটির জন্য একটি getter ও একটি setter — setBalance, setAccountNumber সহ। দেখতে “encapsulated”, কিন্তু আসলে public field-এর লম্বা সংস্করণ। Spring প্রজেক্টে AI প্রায়ই সরাসরি Lombok-এর @Data বসিয়ে দেয়:

@Data                       // Lombok: compile-এর সময় কোড তৈরি করে
public class Account {
    private String accountNumber;
    private long balance;
}
// তৈরি হয়: সব field-এর getter, সব non-final field-এর setter,
// equals, hashCode, toString আর একটি constructor
// ফলে acc.setBalance(-5000) বৈধ!

@Data শুধু-ডেটা class-এর জন্য সুবিধাজনক, আর boilerplate কমায়; কিন্তু নিয়ম-ওয়ালা domain object-এ এটি invariant-এর দরজা খুলে দেয়। AI-এর লেখা কোডে যে ভুলগুলো বারবার দেখা যায়:

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

• সব field private, আর কোনো public field নেই
• Class-এর invariant এক-দুই বাক্যে লিখতে পারি, আর প্রতিটি অবস্থা-বদলানো method তা যাচাই করে
• id, তৈরির তারিখ, ব্যালান্সের মতো field-এর অবাধ setter নেই
• কোনো getter ভেতরের array, list বা অন্য mutable object সরাসরি ফেরত দেয় না
• Constructor বাইরে থেকে আসা array বা list কপি করে রাখে
• Helper class আর method-এর access যতটা সম্ভব কম (private বা package-private)
• নিয়ম ভাঙার একটি চেষ্টা (যেমন ঋণাত্মক টাকা তোলা) চালিয়ে দেখেছি যে সেটা নাকচ হয়