Java class ও object — নকশা থেকে আসল জিনিস

১ · Class হলো নকশা, object হলো আসল জিনিস

পর্ব ১৩ পর্যন্ত আপনি Java-র “মূল ভাষা” শিখেছেন — টাইপ, লুপ, method, array. প্রতিটি প্রোগ্রামে একটি class Main ছিল, আর সব method ছিল static. এবার মডিউল ৩ শুরু, আর এখান থেকে Java তার আসল রূপে আসে: object-ভিত্তিক ভাষা।

পর্ব ০২-এ আপনি কাগজে-কলমে ভেবেছিলেন — একটি সমস্যাকে কয়েকটি জিনিসে ভাগ করা, যারা প্রত্যেকে কিছু জানে আর কিছু করতে পারে। ওয়ালেট জানে তার মালিক আর ব্যালান্স, আর পারে টাকা জমা নিতে, টাকা দিতে। এই “জানা” হলো state, আর “পারা” হলো behaviour. আজ সেই ভাবনাকে Java-র নিয়মে লিখবেন।

Java-র ভাষায়: class হলো একটি নকশা, যা বলে দেয় এই ধরনের প্রতিটি জিনিসের কোন কোন তথ্য থাকবে আর সে কোন কোন কাজ করতে পারবে। object হলো সেই নকশা থেকে বানানো একটি নির্দিষ্ট, আসল জিনিস, যা প্রোগ্রাম চলার সময় মেমরিতে থাকে। একটি object-কে বলা হয় তার class-এর একটি instance — “রিনার অ্যাকাউন্ট হলো BankAccount-এর একটি instance.”

এই পর্বে দুটি পুরোনো ধারণা এক জায়গায় মিলবে। পর্ব ০২ থেকে আসবে নকশার ভাবনা — কোন জিনিস, কী দায়িত্ব। আর পর্ব ০৫ থেকে আসবে মেমরির ছবি — object থাকে heap-এ, ভ্যারিয়েবলে থাকে তার reference. এই দুটি ছবি একসাথে মাথায় রাখতে পারলে বাকি পুরো মডিউল সহজ হয়ে যাবে।

২ · প্রথম class — field, instance method আর dot

বিকাশ বা নগদের মতো একটি মোবাইল ওয়ালেটের অ্যাকাউন্ট ভাবুন। প্রতিটি অ্যাকাউন্ট জানে তার মালিকের নাম আর ব্যালান্স; আর পারে টাকা জমা নিতে আর টাকা তোলার সুযোগ দিতে। Java-তে এর নকশা:

class BankAccount {
    String owner;                // field: মালিকের নাম
    long balance;                // field: ব্যালান্স, টাকায়

    void deposit(long amount) {  // instance method
        balance += amount;
    }

    long getBalance() {
        return balance;
    }
}

তিনটি জিনিস লক্ষ করুন। এক, owner আর balance কোনো method-এর ভেতরে নয়, সরাসরি class-এর ভেতরে — এরা field. পর্ব ১২-এর local variable ছিল এক ডাকের জন্য; field বাঁচে যতদিন object বাঁচে। দুই, deposit-এর আগে static নেই। এটি একটি instance method — কোনো একটি নির্দিষ্ট object-এর ওপর ডাকতে হয়, আর ভেতরে balance লিখলে মানে হয় “যে object-এর ওপর ডাকা হয়েছে, তার balance”. তিন, class-এর নাম বড় হাতের অক্ষরে শুরু (BankAccount), আর প্রতিটি শব্দের প্রথম অক্ষর বড় — একে বলে PascalCase; field আর method-এর নাম ছোট হাতের camelCase.

Object বানানো আর dot দিয়ে ব্যবহার

BankAccount rina = new BankAccount();   // object তৈরি
rina.owner = "Rina";                    // field-এ লেখা
rina.deposit(1500);                     // method ডাকা
long b = rina.getBalance();             // 1500

new হলো object বানানোর চাবি: “BankAccount নকশা থেকে একটি নতুন object বানাও, আর তার ঠিকানা আমাকে দাও।” সেই ঠিকানা বসে rina ভ্যারিয়েবলে, যার টাইপ BankAccount. তারপর dot (.) দিয়ে object-এর ভেতরে ঢোকা: rina.owner মানে “রিনার object-এর owner field”, rina.deposit(1500) মানে “রিনার object-কে বলো ১৫০০ জমা নিতে।” পর্ব ০২-এর ভাষায় এটাই message passing — object-কে একটি বার্তা পাঠানো।

new BankAccount()-এর শেষের বন্ধনী দেখে মনে হয় একটি method ডাকা হচ্ছে। আসলে ডাকা হচ্ছে একটি constructor — object তৈরির মুহূর্তে চলা বিশেষ কোড। আমরা কোনো constructor লিখিনি, তবু কোড চলছে, কারণ class-এ একটিও constructor না থাকলে compiler নিজেই একটি খালি, parameter-হীন constructor বসিয়ে দেয় — একে বলে default constructor. নিজের constructor লিখে শুরুতেই মালিকের নাম দেওয়া, আর this keyword — এগুলো পরের পর্বের (পর্ব ১৬) বিষয়।

Default মান — field কখনো “আবর্জনা” রাখে না

ওপরের কোডে balance-এ আমরা কোনো মান দিইনি। তাহলে নতুন object-এ balance কত? পর্ব ১২-এ দেখেছেন, মান না দিয়ে local variable পড়লে compile error হয়। Field-এর নিয়ম আলাদা: object তৈরির সময় JVM প্রতিটি field-এ একটি default value বসিয়ে দেয় — পর্ব ১৩-এ array-র ঘরে যে মান বসত, ঠিক সেগুলোই।

কেন এই পার্থক্য? Local variable-এর জীবন একটি method-এর ভেতরে, compiler পুরো পথ দেখে নিশ্চিত হতে পারে মান দেওয়া হয়েছে কি না। কিন্তু field যেকোনো method থেকে, যেকোনো ক্রমে পড়া হতে পারে — compiler সেটা প্রমাণ করতে পারে না। তাই Java ঠিক করেছে, field অন্তত একটি নিশ্চিত, পরিচিত মান নিয়ে শুরু করবে। C-তে malloc করা struct-এ পুরোনো আবর্জনা থাকতে পারে; Java-তে কখনো নয়।

আরেকটি নকশা — Student আর গড় নম্বর

একই ধাঁচে একজন শিক্ষার্থীর নকশা। Field হিসেবে একটি array-ও রাখা যায় (পর্ব ১৩):

class Student {
    String name;
    int roll;
    int[] marks;                 // default: null — array নিজে তৈরি করতে হবে

    double average() {
        if (marks == null || marks.length == 0) return 0.0;
        int sum = 0;
        for (int m : marks) sum += m;
        return (double) sum / marks.length;
    }
}

average() কোনো parameter নেয় না — তবু সে জানে কার নম্বরের গড় বের করতে হবে, কারণ সে যে object-এর ওপর ডাকা হয়, সেই object-এর marks ব্যবহার করে। sadia.average() সাদিয়ার গড় দেয়, tanvir.average() তানভীরের। পর্ব ১২-এর static method হলে লিখতে হতো average(sadia.marks) — তথ্য আর কাজ আলাদা থাকত। Object-এ তথ্য আর তার ওপরের কাজ একসাথে থাকে; এটাই object-ভিত্তিক নকশার মূল কথা।

৩ · new চলার সময় মেমরিতে কী ঘটে

পর্ব ০৫-এ দেখেছিলেন, JVM-এর মেমরির দুটি বড় অংশ: stack — প্রতিটি method-ডাকের নিজের খাতা (stack frame), যেখানে local variable থাকে; আর heap — যেখানে সব object থাকে, যতক্ষণ কেউ তাদের ব্যবহার করে। BankAccount acc = new BankAccount(); — এই একটি লাইনে আসলে কয়েকটি আলাদা ঘটনা ঘটে। ধাপে ধাপে দেখুন:

stack: main-এর frame         heap
┌────────────────────┐
│ acc = ?            │       (এখনো কিছু নেই)
└────────────────────┘
শুধু একটি reference রাখার জায়গা — object নয়

stack: main-এর frame         heap
┌────────────────────┐       ┌───────────────────────┐
│ acc = ?            │       │ BankAccount           │
└────────────────────┘       │   owner   = null      │
                             │   balance = 0         │
                             └───────────────────────┘
জায়গা নেওয়া হলো, প্রতিটি field পেল default মান

stack: main-এর frame         heap
┌────────────────────┐       ┌───────────────────────┐
│ acc = ?            │       │ BankAccount  ✔ প্রস্তুত │
└────────────────────┘       │   owner   = null      │
                             │   balance = 0         │
                             └───────────────────────┘
default constructor কিছুই বদলায় না — object এখন ব্যবহারযোগ্য

stack: main-এর frame         heap
┌────────────────────┐       ┌───────────────────────┐
│ acc = ●────────────┼──────▶│ BankAccount           │
└────────────────────┘       │   owner   = null      │
                             │   balance = 0         │
                             └───────────────────────┘
acc-এ object নেই, আছে object-এ পৌঁছানোর reference

stack: main-এর frame         heap
┌────────────────────┐       ┌───────────────────────┐
│ acc = ●────────────┼──────▶│ BankAccount           │
└────────────────────┘       │   owner   = ●─────────┼──▶ [ String "Rina" ]
                             │   balance = 1500      │
                             └───────────────────────┘
dot মানে: তীর ধরে object-এ যাও, তারপর ভেতরে লেখো

এই ছবি থেকে একটি গুরুত্বপূর্ণ সত্য বেরিয়ে আসে: Java-তে acc-এর মতো ভ্যারিয়েবলের টাইপ হলো reference type. পর্ব ০৬-এর আট ধরনের primitive type (int, double, boolean…) ছাড়া বাকি সব — String, array, আপনার নিজের প্রতিটি class — reference type. Primitive ভ্যারিয়েবলের ঘরে থাকে সরাসরি মান; reference ভ্যারিয়েবলের ঘরে থাকে একটি তীর।

৪ · প্রতিটি object-এর নিজের state

একই নকশা থেকে বিশটি ফ্ল্যাট — প্রতিটির মিটারে আলাদা রিডিং। ঠিক তেমনি, একই BankAccount class থেকে দুটি object বানালে প্রতিটির balance আলাদা। এক object-এর field বদলালে অন্যটির গায়ে আঁচড়ও লাগে না। নিচের প্রোগ্রামে রিনা আর করিমের দুটি অ্যাকাউন্ট; এবার withdraw-এ একটি নিয়মও আছে — ব্যালান্সের বেশি টাকা তোলা যাবে না। চালিয়ে দেখুন:

class BankAccount {
    String owner;
    long balance;                          // টাকায়, শুরুতে 0
    void deposit(long amount) { balance += amount; }
    boolean withdraw(long amount) {
        if (amount <= 0 || amount > balance) return false;
        balance -= amount;
        return true;
    }
}
class Main {
    public static void main(String[] args) {
        BankAccount rina = new BankAccount();
        BankAccount karim = new BankAccount();
        rina.owner = "Rina";
        karim.owner = "Karim";
        rina.deposit(1500);
        karim.deposit(300);
        System.out.println("Rina  -500: " + rina.withdraw(500));
        System.out.println("Karim -500: " + karim.withdraw(500));
        System.out.println(rina.owner + " " + rina.balance + ", " + karim.owner + " " + karim.balance);
    }
}

লুকানো receiver — method কীভাবে জানে “কার” balance?

deposit-এর ভেতরে লেখা শুধু balance += amount;. কোথাও লেখা নেই রিনার না করিমের। তবু ঠিক object-টিই বদলায়। রহস্যটা হলো: প্রতিটি instance method-এর ডাকে Java চুপিচুপি একটি অতিরিক্ত জিনিস পাঠায় — dot-এর বাঁ দিকের object-এর reference. Method-এর ভেতরে তার নাম this, আর balance লেখা আসলে this.balance-এর সংক্ষিপ্ত রূপ। যে object-এর ওপর method ডাকা হয়, তাকে বলে receiver. ধাপে ধাপে দেখুন:

1void deposit(long amount) {2    balance += amount;   // আসলে this.balance3}45BankAccount rina  = new BankAccount();6BankAccount karim = new BankAccount();7rina.deposit(500);8karim.deposit(200);

Instance বনাম static — এক ঝলক

তাহলে পর্ব ১২-এর static method কী ছিল? static মানে “class-এর, কোনো object-এর নয়”। static method-এ কোনো this নেই — সে কোনো object-এর ওপর ডাকা হয় না, তাই instance field সরাসরি পড়তেও পারে না। Math.max(3, 7) একটি static method: সর্বোচ্চ মান বের করতে কোনো “Math object”-এর state লাগে না। অন্যদিকে deposit একটি নির্দিষ্ট অ্যাকাউন্টের balance বদলায় — তাই instance method.

Static method-এর ভেতর থেকে instance field পড়তে চাইলে কী হয়? main-এ সরাসরি balance = 10; লিখলে javac বলে non-static variable balance cannot be referenced from a static context — অর্থাৎ “কার balance? এখানে তো কোনো object নেই।” নতুনদের কাছে এটি খুব পরিচিত error. প্রশ্নটা সবসময় একই: এই কাজের জন্য কি একটি নির্দিষ্ট object-এর তথ্য লাগে? লাগলে instance, না লাগলে static. static field আর final-এর পুরো আলোচনা পর্ব ১৮-এ।

৫ · একটি object, দুটি reference — aliasing

পর্ব ১৩-এ array-র সাথে যা দেখেছেন, সব object-এর সাথে তা-ই ঘটে: BankAccount b = a; লিখলে নতুন কোনো object তৈরি হয় না। কপি হয় শুধু তীরটি। এখন দুটি ভ্যারিয়েবল একই object দেখায় — একে বলে aliasing. একটি দিয়ে বদলালে অন্যটি দিয়েও সেই বদল দেখা যায়, কারণ object তো একটাই।

stack            heap
a ●─────────▶ [ #1  balance = 0 ]

একটি object, একটি তীর

stack            heap
a ●─────────┐
            ├─▶ [ #1  balance = 0 ]
b ●─────────┘
নতুন object নেই — শুধু তীরের কপি

stack            heap
a ●─────────┐
            ├─▶ [ #1  balance = 700 ]
b ●─────────┘
b দিয়ে বদলালাম, a দিয়েও 700 দেখা যায়

stack            heap
a ●─────────▶ [ #1  balance = 700 ]
b ●─────────▶ [ #2  balance = 0 ]

শুধু b-এর তীর ঘুরল; a আর #1 অক্ষত

ধাপ ২-৩-এ:  a == b  →  true   (একই object)
ধাপ ৪-এর পরে: a == b  →  false  (দুটি আলাদা object)

== দেখে তীর একই জায়গায় কি না — ভেতরের মান নয়

Identity বনাম equality — একটি ঝলক

দুটি আলাদা Book object, দুটিরই title “পদ্মা নদীর মাঝি”. এরা কি “সমান”? দুই অর্থে প্রশ্ন করা যায়। Identity: এরা কি একই object? উত্তর না, == দেবে false. Equality: এরা কি অর্থের দিক থেকে একই জিনিস (একই বই)? সেটা নির্ভর করে আপনি “সমান” বলতে কী বোঝেন — একই title? একই ISBN? এই প্রশ্নের উত্তর class-এর লেখক দেন equals() method লিখে। আপনার নিজের class-এ equals না লিখলে সেটি ==-এর মতোই আচরণ করে। পর্ব ০৮-এ String-এর বেলায় এটা দেখেছিলেন (== নয়, equals); নিজের class-এ equals ঠিকভাবে লেখা হবে পর্ব ২৩-এ।

নিচের প্রোগ্রামে aliasing, method-এ object পাঠানো, default মান আর identity — চারটিই একসাথে। লাইব্রেরির একটি বই:

class Book {
    String title;
    int timesBorrowed;
    boolean borrowed;
}
class Main {
    static void lend(Book b) {             // reference-এর কপি আসে
        b.borrowed = true;
        b.timesBorrowed++;
    }
    public static void main(String[] args) {
        Book a = new Book();
        System.out.println(a.title + " " + a.timesBorrowed + " " + a.borrowed);
        a.title = "Padma Nadir Majhi";
        Book shelf = a;                    // নতুন object নয়
        lend(shelf);
        System.out.println(a.title + ": " + a.borrowed + ", " + a.timesBorrowed);
        Book c = new Book();
        c.title = "Padma Nadir Majhi";
        System.out.println("a == shelf : " + (a == shelf));
        System.out.println("a == c     : " + (a == c));
        System.out.println("same title : " + a.title.equals(c.title));
    }
}

Object ছাপলে কী আসে — Book@...

কৌতূহলে কেউ লেখেন System.out.println(a);. আউটপুট আসে এমন কিছু:

Book@251a69d7

এটা কোনো ভুল নয়, আবার কাজেরও নয়। প্রতিটি Java class নিঃশব্দে Object নামের একটি মূল class থেকে কিছু method পায়, তার একটি toString(). আপনি নিজে না লিখলে সেটি ফেরত দেয় class-এর নাম, একটি @, আর object-এর hash code — ষোলো-ভিত্তিক (hexadecimal) সংখ্যায়। সংখ্যাটা প্রতিবার চালালে আলাদা হতে পারে, আর এটি মেমরির ঠিকানা নয় (অনেকে তা-ই ভাবেন)। তাই এই কোর্সের চালানো যায় এমন কোডে কখনো object সরাসরি ছাপা হয় না। Object-কে অর্থপূর্ণভাবে ছাপতে তার class-এ নিজের toString() লিখতে হয় — যেমন Book[title=Padma Nadir Majhi, borrowed=true]. কীভাবে, তা পর্ব ২৩-এ।

৬ · null আর NullPointerException

একটি reference ভ্যারিয়েবল কোনো object না দেখিয়েও থাকতে পারে। তখন তার মান null — “তীর নেই”. Field-এ reference টাইপের default মান null; আর আপনি নিজেও লিখতে পারেন Book b = null;. সমস্যা শুরু হয় যখন null-এর ওপর dot চালানো হয় — তীর নেই, অথচ তীর ধরে object-এ যেতে বলা হচ্ছে। JVM তখন ছোড়ে NullPointerException (সংক্ষেপে NPE).

class Library {
    Book featured;               // default: null — কোনো বই রাখা হয়নি
}
// main-এর ভেতরে:
Library lib = new Library();
lib.featured.borrow();           // featured null — এখানে ভেঙে পড়বে

Java 14-এর আগে মেসেজ ছিল শুধু java.lang.NullPointerException আর লাইন নম্বর। এক লাইনে a.b.c.d() থাকলে বোঝার উপায় ছিল না কোনটি null. Java 14-এ JEP 358 নিয়ে আসে “helpful NullPointerException” — এখন JVM নিজেই বলে দেয় কী করতে গিয়ে, আর কোন জিনিসটি null ছিল বলে ব্যর্থ হলো (Java 15 থেকে এটি ডিফল্টভাবে চালু)। OpenJDK 21-এ চালিয়ে পাওয়া আসল মেসেজ:

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Book.borrow()" because "lib.featured" is null

পড়ুন বাঁ থেকে ডানে: “Book.borrow() ডাকা গেল না, কারণ lib.featured হলো null.” সাথে সাথে বোঝা যায় — lib ঠিক আছে, সমস্যা featured field-এ, যেখানে কেউ কোনো বই রাখেনি। Field পড়তে গেলে মেসেজ হয় Cannot read field "title" because ... is null, আর লিখতে গেলে Cannot assign field.

NPE থেকে বাঁচার অভ্যাস

• শুরুতেই মান দিন। যে field কখনো null হওয়া উচিত নয়, তাকে object তৈরির সময়েই মান দিন — constructor দিয়ে (পর্ব ১৬), বা ঘোষণার সাথেই (int[] marks = new int[0];).
• সীমানায় যাচাই। বাইরে থেকে আসা reference (method-এর parameter) null হতে পারলে শুরুতেই পরীক্ষা করুন: if (b == null) return false;. Java-র নিজের Objects.requireNonNull(b) null পেলে সাথে সাথে স্পষ্ট মেসেজসহ ব্যর্থ হয় — পরে গভীরে গিয়ে ভাঙার চেয়ে ভালো।
• “নেই” বোঝাতে null ফেরত দেওয়ার আগে ভাবুন। খালি তালিকা ফেরত দেওয়া (null-এর বদলে) প্রায়ই নিরাপদ; আর “থাকতেও পারে, না-ও থাকতে পারে” বোঝাতে Optional আছে (পর্ব ৩৬)।

৭ · Method-এ object আর garbage collection

অংশ ৫-এর প্রোগ্রামে lend(shelf) দেখলেন: method পায় reference-এর একটি কপি, আর সেই কপি ধরে আসল object-এর ভেতরটা বদলাতে পারে। পর্ব ১২-এর নিয়মই — pass by value, যেখানে object-এর “মান” হলো তার reference. দুটি ফল মনে রাখুন। (১) Method object-এর field বদলালে caller সেই বদল দেখে। (২) Method নিজের parameter-এ b = new Book(); বসালে caller কিছুই টের পায় না — শুধু method-এর নিজের তীর ঘুরল। তাই কোনো method যদি parameter-এ পাওয়া object বদলায়, সেটা তার নাম বা Javadoc-এ স্পষ্ট বলা উচিত (lend, markBorrowed) — নইলে caller অবাক হবেন।

যে object-এর দিকে কেউ তাকিয়ে নেই

Java-তে object মুছে ফেলার কোনো delete নেই। তাহলে মেমরি ফেরত আসে কীভাবে? পর্ব ০৫-এ দেখেছেন: garbage collection. GC কিছু শুরুর বিন্দু থেকে — যেমন চলমান method-গুলোর local variable, যাদের বলে GC root — তীর ধরে ধরে হাঁটে। যে object-এ কোনো পথেই পৌঁছানো যায় না, সে আর কারও কাজে আসবে না; সেই object মুছে ফেলার যোগ্য।

stack            heap
x ●─────────▶ [ বই #1 ]
y ●─────────▶ [ বই #2 ]

দুটি object-ই পৌঁছানো যায়

stack            heap
x ●─────────┐   [ বই #1 ]  ← কোনো তীর নেই
            ├─▶ [ বই #2 ]
y ●─────────┘
#1 এখন unreachable — GC-র যোগ্য

stack            heap
x ●───────────▶ [ বই #2 ]
y = null         [ বই #1 ]  (যোগ্য, এখনো পড়ে আছে)

#2-এ x দিয়ে এখনো পৌঁছানো যায় — নিরাপদ

stack            heap
(frame নেই)      [ বই #1 ]  ← যোগ্য
                 [ বই #2 ]  ← যোগ্য

local variable-ই ছিল শেষ পথ; এখন দুটিই unreachable

stack            heap
                 (জায়গা খালি — আবার ব্যবহারযোগ্য)

কখন চলবে, JVM ঠিক করে — আপনি নন

একটি সূক্ষ্ম কথা: GC থাকলেও Java-তে memory leak হতে পারে। কোনো দীর্ঘজীবী object — যেমন একটি static তালিকা — যদি এমন object-এর reference ধরে রাখে, যা আর দরকার নেই, তাহলে সেগুলো reachable থেকে যায়, আর GC তাদের ছোঁয় না। GC শুধু “পৌঁছানো যায় না” এমন object সরায়, “দরকার নেই” এমন object নয় — সেটা বোঝা আপনার দায়িত্ব।

৮ · বাস্তব প্রজেক্টে class — ফাইল, UML আর নকশা

এক ফাইলে এক public class

এই পাতার runner-এ সব class এক ফাইলে, কোনোটিতে public নেই। বাস্তব প্রজেক্টে রীতি ভিন্ন, আর একটি নিয়ম compiler নিজেই চাপিয়ে দেয়:

• একটি .java ফাইলে বড়জোর একটি top-level public class, আর ফাইলের নাম হুবহু সেই class-এর নামে। public class BankAccount থাকবে BankAccount.java-এ। নাম না মিললে javac বলে class BankAccount is public, should be declared in a file named BankAccount.java.
• রীতি: প্রতিটি class নিজের ফাইলে। public ছাড়া class একই ফাইলে রাখা বৈধ, কিন্তু দলগত কাজে প্রায় সবাই প্রতিটি class আলাদা ফাইলে রাখেন — খুঁজে পাওয়া সহজ, Git-এ পরিবর্তন দেখা সহজ।
• public ছাড়া class শুধু নিজের package-এর ভেতর থেকে ব্যবহার করা যায়। কে কোন class, field বা method দেখতে পাবে — এই নিয়মগুলোকে বলে access modifier, পর্ব ১৭-এর বিষয়।

wallet-app/src/
├── Main.java           public class Main        (main method এখানে)
├── BankAccount.java    public class BankAccount
└── Transaction.java    public class Transaction

UML class diagram — কোড লেখার আগের ছবি

দলে আলোচনার সময় পুরো কোড না লিখে class-এর নকশা আঁকা হয় একটি মানক চিহ্নে — UML class diagram. প্রতিটি class একটি বাক্স, তিন তলা: ওপরে নাম, মাঝে field, নিচে method. নামের আগের চিহ্ন বলে কে দেখতে পাবে: - মানে private, + মানে public, ~ মানে package-এর ভেতরে। টাইপ লেখা হয় নামের পরে, কোলনের পরে।

┌─────────────────────────────────────┐
│             BankAccount             │  ← নাম
├─────────────────────────────────────┤
│ - owner : String                    │  ← field (state)
│ - balance : long                    │
├─────────────────────────────────────┤
│ + deposit(amount : long) : void     │  ← method (behaviour)
│ + withdraw(amount : long) : boolean │
│ + getBalance() : long               │
└─────────────────────────────────────┘

ছবিতে field-গুলো - (private) — আমাদের এখনকার কোডে নয়, কিন্তু পর্ব ১৭-এর পর এটাই হবে লক্ষ্য। দুটি class-এর সম্পর্ক বোঝাতে বাক্সের মাঝে রেখা টানা হয় (“একটি BankAccount-এর অনেক Transaction”); inheritance-এর জন্য ফাঁপা ত্রিভুজ-মাথার তীর — পর্ব ১৯-এ দেখবেন। IntelliJ-সহ অনেক টুল কোড থেকে এই ছবি বানাতে পারে, আর ইন্টারভিউ বা লিখিত পরীক্ষায় “ছোট একটি system-এর class diagram আঁকুন” ধরনের প্রশ্ন আসতে পারে।

বিবরণ থেকে class — বিশেষ্য আর ক্রিয়া

কোন কোন class লাগবে, বুঝবেন কীভাবে? পর্ব ০২-এর কৌশল — বিশেষ্য-ক্রিয়া বিশ্লেষণ. একটি ছোট লাইব্রেরি সিস্টেমের বিবরণ পড়ুন:

• মোটা বিশেষ্য → class: Book, Member, Library.
• দাগ দেওয়া বিশেষ্য (কোনো কিছুর গুণ) → field: Book-এর title, author; Member-এর ধার নেওয়া বইয়ের তালিকা।
• ক্রিয়া → method, যার কাছে তথ্য আছে তার কাছে: member.borrow(book), member.returnBook(book), library.find(title).
• নিয়ম → method-এর ভেতরের যাচাই: “সর্বোচ্চ তিনটি” — borrow চতুর্থ বই ফিরিয়ে দেবে, ঠিক যেমন withdraw ব্যালান্সের বেশি টাকা ফিরিয়েছে।

এরপর প্রতিটি class-এর জন্য পর্ব ০২-এর CRC কার্ড — দায়িত্ব কী, সহযোগী কে — আর তারপর UML বাক্স। কোড আসে সবার শেষে। একটি সতর্কসংকেত মনে রাখুন: যদি একটি class-এর নাম হয় LibraryManager আর তার ভেতরে বই, সদস্য, জরিমানা, রিপোর্ট সব থাকে, তাহলে সম্ভবত আপনি একটি god class বানাচ্ছেন — দায়িত্বগুলো আলাদা class-এ ভাগ করুন।

৯ · AI-এর যুগে — class-এর নকশা যাচাই করা আপনার কাজ

AI-কে “একটি লাইব্রেরি ম্যানেজমেন্ট সিস্টেম Java-তে লিখে দাও” বললে কয়েক সেকেন্ডে কয়েকশো লাইন আসে, আর কোড চলেও। কিন্তু class-এর নকশায় AI-এর কিছু পরিচিত অভ্যাস আছে, যা ছোট প্রজেক্টে চোখে পড়ে না, আর বড় হলে দলকে ভোগায়। কোড চলে কি না, সেটা compiler বলবে; নকশা ঠিক কি না, সেটা বলতে হবে আপনাকে।

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

• প্রতিটি class-এর দায়িত্ব এক বাক্যে বলতে পারি, আর কোনো class “সব কিছু” করছে না
• প্রতিটি field সত্যিই object-এর state; অস্থায়ী হিসাবের মান local variable-এ আছে, field-এ নয়
• প্রতিটি reference field কোথায় মান পায় জানি — null থেকে গেলে কোথায় NPE হতে পারে, দেখেছি
• যেখানে b = a আছে, সেখানে বুঝেছি এটা একই object, কপি নয়
• নিয়ম আছে এমন field (ব্যালান্স, নম্বর) বাইরে থেকে সরাসরি বদলানো যায় কি না পরীক্ষা করেছি
• কোথাও object সরাসরি ছাপা হচ্ছে না, বা হলে সেই class-এ নিজের toString আছে