abstract class আর interface — অর্ধেক-তৈরি parent ও চুক্তি

১ · দুটি সমস্যা — ভাগ করা কোড আর একই চুক্তি

পর্ব ২০-এ polymorphism দেখেছেন: parent টাইপের একটি ভ্যারিয়েবল (সেখানে Payment, এখানে ধরুন Shape) আসলে Circle বা Rect object দেখাতে পারে, আর area() ডাকলে চলার সময় আসল object-এর method চলে (dynamic dispatch). কিন্তু সেখানে একটি অস্বস্তিকর প্রশ্ন রয়ে গিয়েছিল। Parent Shape-এর নিজের area() কী ফেরত দেবে? শূন্য? “আকৃতি” বলে কোনো আসল জিনিসই নেই — আছে বৃত্ত, আয়ত, ত্রিভুজ। শূন্য ফেরত দেওয়া মানে একটি মিথ্যা উত্তর, আর কেউ subclass-এ area() লিখতে ভুলে গেলে প্রোগ্রাম নীরবে ০ দেখাবে।

দ্বিতীয় সমস্যাটি আরও বড়। একটি অনলাইন দোকানে অর্ডার পাঠানোর পর গ্রাহককে খবর দিতে হবে — কখনো SMS-এ, কখনো Email-এ, পরে হয়তো WhatsApp-এ। SmsSender আর EmailSender-এর মধ্যে কোনো পারিবারিক সম্পর্ক নেই; একটি মোবাইল অপারেটরের সাথে কথা বলে, আরেকটি মেইল সার্ভারের সাথে। তাদের কোনো field বা কোড ভাগ করার নেই। তবু দোকানের কোড চায় দুটিকেই একইভাবে ডাকতে: “এই নম্বরে/ঠিকানায় এই বার্তাটা পাঠাও।”

Java এই দুই সমস্যার জন্য দুটি আলাদা হাতিয়ার দেয়:

দুটি ধারণাই আসলে abstraction-এর হাতিয়ার: ব্যবহারকারী জানবে কী করা যায়, কীভাবে হয় তা লুকানো থাকবে। পার্থক্য হলো — abstract class কোড আর state ভাগ করে, interface শুধু আচরণের প্রতিশ্রুতি ভাগ করে।

২ · abstract class — যে parent-এর object হয় না

কোনো class-এর আগে abstract keyword বসালে সে হয় abstract class. তার ভেতরে শরীরহীন method ঘোষণা করা যায় — শুধু signature, তারপর সেমিকোলন, কোনো { } নেই। এমন method-কে বলে abstract method:

abstract class Shape {
    private final String name;              // state — সব আকৃতির নাম থাকে

    Shape(String name) {                    // constructor-ও আছে!
        this.name = name;
    }

    abstract double area();                 // শরীর নেই — subclass দেবে

    String describe() {                     // সাধারণ (concrete) method
        return String.format("%s: area %.2f", name, area());
    }
}

এখানে তিনটি জিনিস একসাথে আছে, আর তিনটিই গুরুত্বপূর্ণ। name হলো ভাগ করা state; describe() হলো ভাগ করা আচরণ, যা সব আকৃতির জন্য একইভাবে কাজ করে; আর area() হলো ফাঁকা ঘর, যা প্রতিটি আকৃতিকে নিজে পূরণ করতে হবে। সব method-এর শরীর আছে এমন সাধারণ class-কে বলা হয় concrete class.

নিয়ম ১ — abstract class-এর object বানানো যায় না

Shape s = new Shape("কিছু একটা");   // ✗

Main.java:6: error: Shape is abstract; cannot be instantiated
        Shape s = new Shape("কিছু একটা");
                  ^
1 error

যুক্তিটা সহজ: এই object-এ কেউ area() ডাকলে কোন কোড চলবে? কোনো কোডই নেই। তাই compiler আগেভাগেই আটকে দেয়। কিন্তু Shape টাইপের ভ্যারিয়েবল রাখা সম্পূর্ণ বৈধ — Shape s = new Circle(2); — কারণ ভ্যারিয়েবল যে object দেখাবে, সেটি সবসময় কোনো concrete subclass-এর হবে।

নিয়ম ২ — subclass হয় সব ফাঁকা ঘর পূরণ করবে, নয়তো নিজেও abstract হবে

class Circle extends Shape {
    // area() লিখতে ভুলে গেছি
}

Main.java:4: error: Circle is not abstract and does not override abstract method area() in Shape
class Circle extends Shape {
^
1 error

ঠিক এই error-টিই পর্ব ২০-এর “parent-এ শূন্য ফেরত দেওয়া” সমাধানের চেয়ে abstract method-কে ভালো করে তোলে। ভুলে যাওয়া আর নীরব bug থাকে না — compile-ই হয় না। আর যদি এমন একটি মাঝের class চান যেটা কিছু ঘর পূরণ করবে, বাকিটা তার subclass-এর জন্য রেখে দেবে, তাহলে সেটিকেও abstract ঘোষণা করুন।

আরও কয়েকটি নিয়ম, এক নজরে

• Constructor থাকতে পারে। Object সরাসরি বানানো না গেলেও subclass-এর constructor super(...) দিয়ে একে ডাকে (পর্ব ১৯)। ভাগ করা field-এর শুরুর মান এখানেই বসে।
• একটিও abstract method না থাকলেও class abstract হতে পারে — শুধু এটুকু বোঝাতে যে “আমাকে সরাসরি ব্যবহার করবেন না।” কিন্তু উল্টোটা নয়: যে class-এ একটি abstract method আছে, তাকে abstract হতেই হবে।
• abstract-এর সাথে final, private বা static মেলে না। abstract method-এর অর্থই হলো “subclass override করবে” — final (override নিষেধ), private (subclass দেখতেই পায় না) বা static (object-এর ওপর নির্ভর করে না) এর সাথে সাংঘর্ষিক। একইভাবে abstract final class-ও অর্থহীন, compile error.

এবার দেখা যাক সবচেয়ে সুন্দর অংশটি: parent-এর সাধারণ method describe() ভেতর থেকে abstract area()-কে ডাকে — যার কোড parent লেখেইনি। তাহলে কোন কোড চলে? “পরে” চাপুন:

1abstract class Shape {2    private final String name;3    Shape(String n) { name = n; }4    abstract double area();5    String describe() {6        return name + ": " + area();7    }8}9class Circle extends Shape {10    private final double r;11    Circle(double r) { super("Circle"); this.r = r; }12    double area() { return Math.PI * r * r; }13}14Shape s = new Circle(2);15System.out.println(s.describe());

এবার পুরো উদাহরণটি — দুটি আলাদা আকৃতি, একটি Shape[] array, আর একটিই লুপ। চালিয়ে দেখুন:

abstract class Shape {
    private final String name;
    Shape(String name) { this.name = name; }
    abstract double area();
    String describe() {
        return String.format("%s: area %.2f", name, area());
    }
}
class Circle extends Shape {
    private final double r;
    Circle(double r) { super("Circle"); this.r = r; }
    @Override double area() { return Math.PI * r * r; }
}
class Rect extends Shape {
    private final double w, h;
    Rect(double w, double h) { super("Rect"); this.w = w; this.h = h; }
    @Override double area() { return w * h; }
}
class Main {
    public static void main(String[] args) {
        Shape[] shapes = { new Circle(2), new Rect(3, 4) };
        for (Shape s : shapes) System.out.println(s.describe());
    }
}

৩ · Template Method — parent ঠিক করে ক্রম, child পূরণ করে ধাপ

ওপরের describe() আসলে একটি বিখ্যাত নকশার ছোট রূপ। ধরুন একটি দোকানের সফটওয়্যারে অনেক ধরনের রিপোর্ট লাগে — বিক্রির রিপোর্ট, স্টকের রিপোর্ট, বাকির রিপোর্ট। প্রতিটির শুরুতে একই শিরোনাম, শেষে একই পাদটীকা; শুধু মাঝের অংশ আলাদা। প্রতিটি রিপোর্ট class-এ শিরোনাম আর পাদটীকা কপি করলে, দোকানের নাম বদলালে দশ জায়গায় বদলাতে হবে।

abstract class ReportGenerator {
    public final String generate() {            // ক্রম — কেউ বদলাতে পারবে না
        return header() + body() + footer();
    }
    protected String header() { return "=== ABCL Shop ===\n"; }
    protected abstract String body();             // একমাত্র ফাঁকা ঘর
    protected String footer() { return "--- শেষ ---\n"; }
}

class SalesReport extends ReportGenerator {
    @Override protected String body() { return "আজকের বিক্রি: 12500 টাকা\n"; }
}

class StockReport extends ReportGenerator {
    @Override protected String body() { return "চা পাতা: 40 প্যাকেট বাকি\n"; }
}

এই কাঠামোর নাম Template Method pattern. generate() হলো “template” — কাজের ধাপগুলোর ক্রম সে নিজে ধরে রাখে, আর final হওয়ায় কোনো subclass সেই ক্রম ভাঙতে পারে না। ধাপগুলোর কিছু parent নিজে করে (header, footer), কিছু subclass-কে দিয়ে করায় (body). protected মানে subclass দেখতে পায়, কিন্তু বাইরের সাধারণ কোড সরাসরি ডাকবে না (পর্ব ১৭)। new SalesReport().generate() ডাকলে কী ঘটে, ধাপে ধাপে দেখুন:

SalesReport-এ generate() নেই → parent-এরটা চলে
ক্রম: header() → body() → footer()

=== ABCL Shop ===

=== ABCL Shop ===
আজকের বিক্রি: 12500 টাকা

=== ABCL Shop ===
আজকের বিক্রি: 12500 টাকা
--- শেষ ---

=== ABCL Shop ===
চা পাতা: 40 প্যাকেট বাকি
--- শেষ ---

JDK-তেও এই pattern আছে: java.io.InputStream একটি abstract class, যার abstract method শুধু একটি — একটি byte পড়া, read(). একসাথে অনেক byte পড়ার read(byte[], int, int)-এর মতো method-গুলো parent নিজেই সেই একটি method দিয়ে বানিয়ে দেয়। ফাইল, নেটওয়ার্ক, মেমরি — যেকোনো উৎসের জন্য শুধু একটি method লিখলেই পুরো stream পাওয়া যায় (দরকার হলে দ্রুততার জন্য বাকিগুলোও override করা যায়)। একইভাবে AbstractList থেকে get আর size লিখলেই একটি পুরো List পেয়ে যান।

৪ · interface — একটি চুক্তি, অনেক সইকারী

এবার দ্বিতীয় সমস্যায় ফেরা যাক: SMS আর Email পাঠানোর দুটি সম্পর্কহীন class. এদের মধ্যে ভাগ করার মতো কোনো কোড নেই, শুধু একটি প্রতিশ্রুতি আছে — “আমি একটি বার্তা পাঠাতে পারি।” এই প্রতিশ্রুতিকে Java-তে লেখা হয় একটি interface হিসেবে:

interface MessageSender {
    boolean send(String to, String text);   // শুধু চুক্তি, শরীর নেই
}

class SmsSender implements MessageSender {
    public boolean send(String to, String text) {
        // মোবাইল অপারেটরের gateway-তে পাঠানো
        return true;
    }
}

class EmailSender implements MessageSender {
    public boolean send(String to, String text) {
        // মেইল সার্ভারে পাঠানো
        return true;
    }
}

Class-এর পরে implements লিখে সে ঘোষণা করে: “আমি এই চুক্তি মানি।” তারপর চুক্তির প্রতিটি method-এর শরীর দেওয়া তার দায়িত্ব — না দিলে abstract class-এর মতোই is not abstract and does not override abstract method error. Interface-এর ভেতরে লেখা সাধারণ method নিজে থেকেই public abstract; আলাদা করে লিখতে হয় না।

নতুনরা এখানে একটি নির্দিষ্ট ভুল প্রায়ই করেন: implement করা method-এ public লিখতে ভুলে যাওয়া।

Main.java:3: error: print() in Doc cannot implement print() in Printable
    void print() { }
         ^
  attempting to assign weaker access privileges; was public
1 error

Interface-এর method public, তাই যে class তা implement করে সে access কমাতে পারে না — চুক্তিতে লেখা আছে “সবাই ডাকতে পারবে”, আর আপনি বলছেন “শুধু package-এর ভেতরের লোক”। সেটা চুক্তিভঙ্গ। ঠিক এই কারণেই ওপরের কোডে SmsSender-এর send-এর সামনে public লেখা।

একটি class, অনেক interface

Java-তে একটি class-এর parent class একটিই হতে পারে (পর্ব ১৯)। কিন্তু interface যত খুশি implement করা যায়। একটি অফিস অ্যাপের Invoice ছাপানো যায়, আবার লিংক দিয়ে শেয়ারও করা যায়:

interface Printable { void print(); }
interface Shareable { String link(); }

class Invoice implements Printable, Shareable {
    public void print() { System.out.println("Printing invoice"); }
    public String link() { return "abcl.link/inv-7"; }
}

এটাকে বলা হয় টাইপের multiple inheritance: একটি Invoice object একই সাথে Invoice, Printable আর Shareable — তিনটি টাইপের ভ্যারিয়েবলেই রাখা যায়। প্রিন্টারের কোড চায় শুধু Printable, শেয়ারের কোড চায় শুধু Shareable; কেউই জানে না বা জানার দরকার নেই যে জিনিসটা আসলে একটি চালান। কিন্তু একটি সূক্ষ্ম নিয়ম আছে — ভ্যারিয়েবলের টাইপ ঠিক করে আপনি কোন method ডাকতে পারবেন:

1interface Printable { void print(); }2interface Shareable { String link(); }3class Invoice implements Printable, Shareable {4    public void print() { ... }5    public String link() { ... }6}7Invoice inv = new Invoice();8Printable p = inv;9Shareable s = inv;10p.print();11String url = s.link();12p.link();   // ?

Interface অন্য interface-কেও extends করতে পারে, এমনকি একসাথে কয়েকটিকে: interface Document extends Printable, Shareable { }. যে class Document implement করবে, তাকে দুটি চুক্তিরই সব method দিতে হবে।

৫ · Interface-এর ভেতরে আর কী থাকে — constant, default, static, private

শুরুতে (Java 1.0 থেকে Java 7 পর্যন্ত) interface-এ থাকতে পারত মাত্র দুটি জিনিস: abstract method আর constant. এখন আরও তিনটি যোগ হয়েছে। প্রতিটির পেছনে একটি বাস্তব কারণ আছে।

Constant — এবং কেন “constant interface” একটি ভুল নকশা

Interface-এ লেখা যেকোনো field নিজে থেকেই public static final — অর্থাৎ একটি constant, যা কেউ বদলাতে পারে না:

interface Limits {
    int MAX = 5;          // আসলে public static final int MAX = 5;
}
// কোথাও: Limits.MAX = 6;

Main.java:3: error: cannot assign a value to static final variable MAX

তাই interface-এ কোনো object-ভিত্তিক state রাখা অসম্ভব — প্রতিটি object-এর আলাদা মান থাকবে এমন field interface-এ হয় না। এটাই abstract class-এর সাথে সবচেয়ে বড় পার্থক্য।

পুরোনো Java কোডে একটি অভ্যাস দেখা যেত: শুধু constant রাখার জন্য একটি interface বানানো, তারপর যেকোনো class-এ implements AppConstants লিখে constant-গুলো নাম ধরে সরাসরি ব্যবহার করা। একে বলে constant interface anti-pattern. Joshua Bloch Effective Java-তে একে interface-এর অপব্যবহার বলেছেন। কারণ implements মানে একটি প্রকাশ্য প্রতিশ্রুতি — “আমি এই টাইপ।” OrderService implements AppConstants বলছে যে order service একটি “constant-এর তালিকা” টাইপের জিনিস, যা অর্থহীন। তার ওপর constant-গুলো class-এর public API-তে ঢুকে যায় আর সব subclass-এও ছড়ায়। সঠিক পথ: সম্পর্কিত constant থাকুক যে class-এর সাথে সম্পর্কিত তার ভেতরে (Integer.MAX_VALUE-এর মতো), নির্দিষ্ট কয়েকটি মান হলে enum (পর্ব ২৪), আর নাম ছোট করতে চাইলে import static.

default method — Java 8-এর “interface evolution” সমস্যার সমাধান

২০১৪ সালে Java 8 lambda নিয়ে এলো, আর সাথে একটি কঠিন প্রশ্ন। সবাই চাইছিল list.forEach(x -> ...) লিখতে। কিন্তু List, Collection, Iterable — এগুলো interface, আর পৃথিবীজুড়ে লাখো class এগুলো implement করে, যার অনেকগুলো JDK-র বাইরে, অন্য কোম্পানির library-তে। Interface-এ একটি নতুন abstract method যোগ করলেই সেই সব class হঠাৎ “does not override abstract method” error দিত। Interface একবার প্রকাশ হলে আর বদলানো যায় না — এই ছিল পুরোনো নিয়ম।

সমাধান: default method — শরীরসহ একটি interface method, যার সামনে default লেখা। যে class নিজে না লেখে, সে এই শরীরটি পায়; যে চায়, override করে। Iterable-এ Java 8-এ ঠিক এভাবে forEach যোগ হয়েছে:

// JDK-র Iterable-এর সরল রূপ
public interface Iterable<T> {
    Iterator<T> iterator();                          // পুরোনো চুক্তি

    default void forEach(Consumer<? super T> action) { // Java 8-এ যোগ
        for (T t : this) action.accept(t);
    }
}

পুরোনো সব class কোনো পরিবর্তন ছাড়াই forEach পেয়ে গেল, কারণ তারা iterator() আগেই দিত, আর default method সেটার ওপর ভর করেই লেখা। একইভাবে Collection-এ এলো stream() আর removeIf(), List-এ এলো sort(). খেয়াল করুন, default method নিজের কোনো field রাখতে পারে না — সে শুধু interface-এর অন্য method ডেকে কাজ করে। তাই default method থাকা সত্ত্বেও interface state-হীনই থাকে।

static method আর private method

Java 8 থেকে interface-এ static method-ও রাখা যায় — সাধারণত সেই interface-এর object বানানোর বা সহায়ক কাজের জন্য। আগে এর জন্য আলাদা “সঙ্গী” class লাগত: Collection-এর জন্য Collections, Path-এর জন্য Paths. এখন List.of(...), Map.of(...), Comparator.comparing(...) সরাসরি interface-এই থাকে। এগুলো ডাকতে হয় interface-এর নাম দিয়েই — implement করা class এগুলো উত্তরাধিকার সূত্রে পায় না।

Java 9 থেকে এলো private interface method. দুটি default method-এ একই কয়েক লাইন লাগলে সেটা একটি private method-এ রাখা যায়, যা চুক্তির অংশ নয় — বাইরে থেকে দেখা যায় না:

interface PaymentGateway {
    boolean charge(String orderId, long amountPaisa);   // চুক্তি

    default long totalWithFee(long amountPaisa) {         // সবাই পায়
        return amountPaisa + fee(amountPaisa);
    }
    private long fee(long amountPaisa) {                  // ভেতরের সাহায্যকারী
        return amountPaisa / 100;                         // ধরা যাক ১%
    }
    static PaymentGateway alwaysOk() {                    // কারখানা method
        return (id, amount) -> true;
    }
}

শেষ লাইনের (id, amount) -> true একটি lambda — এটা কীভাবে একটি interface-এর object হয়ে যায়, তা অংশ ৭-এ সংক্ষেপে আর পর্ব ৩৪-এ বিস্তারিত দেখবেন। এক নজরে সারাংশ:

Diamond সংঘর্ষ — দুটি interface, একই default method

Default method আসার পর একটি পুরোনো ভয় ফিরে এলো। একটি class যদি দুটি interface implement করে, আর দুটিতেই একই নামের default method থাকে — কোনটা চলবে? C++-এ multiple inheritance-এর এই ধাঁধাকে বলে diamond problem. Java-র উত্তর পরিষ্কার: compiler অনুমান করে না, আপনাকে সিদ্ধান্ত নিতে বাধ্য করে।

1interface Printable {2    default String info() { return "Printable"; }3}4interface Shareable {5    default String info() { return "Shareable"; }6}7class Report implements Printable, Shareable {8    @Override9    public String info() {10        return Printable.super.info() + " + " + Shareable.super.info();11    }12}13System.out.println(new Report().info());

কেন এখানে C++-এর মতো জটিলতা হয় না? কারণ interface-এ state নেই। C++-এর diamond-এর আসল যন্ত্রণা হলো একই parent-এর field দুই পথে দুবার চলে আসা; Java-র interface-এ field-ই নেই (constant ছাড়া), তাই সংঘর্ষ হতে পারে শুধু method-এর শরীরে — আর সেটা মেটানোর পরিষ্কার নিয়ম আছে।

৬ · Interface একটি টাইপ — implementation নয়, চুক্তির ওপর নির্ভর করুন

আপনি সম্ভবত এমন লাইন দেখেছেন, আর পর্ব ৩০-এ নিজেও লিখবেন:

List<String> names = new ArrayList<>();

বাঁ পাশে List — একটি interface; ডান পাশে ArrayList — একটি concrete class. কেন ArrayList<String> names লেখা হলো না? কারণ বাকি কোড জানবে শুধু List-এর চুক্তি (add, get, size…)। কাল যদি দেখা যায় শুরুতে ঢোকানো বেশি হচ্ছে আর LinkedList ভালো, বা একটি অপরিবর্তনীয় তালিকা চাই — শুধু ডান পাশ বদলাবেন। Method-এর parameter হিসেবে List নিলে যে কেউ যেকোনো ধরনের তালিকা পাঠাতে পারবে। ১৯৯৪ সালের বিখ্যাত বই Design Patterns-এ (“Gang of Four”) একে বলা হয়েছে program to an interface, not an implementation.

NotificationService — নিচের স্তরের ওপর নয়, চুক্তির ওপর ভর

অংশ ১-এর দোকানে ফিরে যাই। অর্ডার পাঠানো হলে খবর দেওয়ার কোড যদি সরাসরি new SmsSender() বানায়, তাহলে তিনটি সমস্যা: Email-এ বদলাতে service-এর কোড বদলাতে হবে; টেস্ট চালালেই আসল SMS চলে যাবে (আর টাকা কাটবে!); আর SMS gateway বন্ধ থাকলে টেস্টও ব্যর্থ হবে। সমাধান — service জানবে শুধু MessageSender চুক্তি, আর কোন sender ব্যবহার হবে সেটা বাইরে থেকে constructor দিয়ে দেওয়া হবে:

interface MessageSender {
    boolean send(String to, String text);
    default String channel() { return "unknown"; }
}
class SmsSender implements MessageSender {
    public boolean send(String to, String text) {
        System.out.println("SMS -> " + to + ": " + text);
        return true;
    }
    @Override public String channel() { return "SMS"; }
}
class FakeSender implements MessageSender {        // টেস্টের জন্য নকল
    String last = "none";
    public boolean send(String to, String text) { last = to; return true; }
}
class NotificationService {
    private final MessageSender sender;
    NotificationService(MessageSender sender) { this.sender = sender; }
    void orderShipped(String phone, int orderId) {
        sender.send(phone, "Order #" + orderId + " is on the way");
    }
}
class Main {
    public static void main(String[] args) {
        var sms = new SmsSender();
        new NotificationService(sms).orderShipped("01711000000", 42);
        var fake = new FakeSender();
        new NotificationService(fake).orderShipped("01811000000", 7);
        System.out.println("fake last: " + fake.last + ", channels: " + sms.channel() + "/" + fake.channel());
    }
}

এই নকশার দুটি নাম আছে, আর দুটিই ইন্টারভিউতে আসে। কে কার ওপর নির্ভর করবে — সেই নীতির নাম Dependency Inversion Principle: ওপরের স্তরের নিয়ম (খবর দেওয়া) নিচের স্তরের খুঁটিনাটির (SMS gateway) ওপর নির্ভর করবে না; দুটিই নির্ভর করবে একটি abstraction-এর (MessageSender) ওপর। আর কীভাবে নির্ভরতা পৌঁছায় — বাইরে থেকে constructor দিয়ে দেওয়া — তার নাম dependency injection. পর্ব ৪৭-এ JUnit-এর সাথে এমন নকল object-কে বলা হবে mock, আর পর্ব ৫০-এ Spring Boot এই injection নিজে থেকেই করে দেবে।

পেমেন্ট gateway — একই চুক্তি, অনেক প্রদানকারী

একটি ই-কমার্স সাইট মোবাইল ওয়ালেট আর কার্ড দুই পথেই টাকা নেয়। প্রতিটি প্রদানকারীর API সম্পূর্ণ আলাদা। কিন্তু checkout-এর কোড চায় একটিই প্রশ্ন করতে: “এই অর্ডারের এত টাকা কাটো।” তাই অংশ ৫-এর PaymentGateway চুক্তি, আর প্রতিটি প্রদানকারীর জন্য একটি class — BkashGateway, NagadGateway, CardGateway. নতুন প্রদানকারী যোগ হলে checkout-এর কোড বদলায় না, শুধু নতুন class আসে। চুক্তিতে টাকা long পয়সায় রাখা হয়েছে — double-এ টাকার হিসাব কেন বিপজ্জনক, তা পর্ব ০৬-এ দেখেছেন।

৭ · Marker, functional আর JDK-র চেনা interface

Marker interface — শূন্য চুক্তি, শুধু একটি চিহ্ন

কিছু interface-এ একটিও method নেই। যেমন java.io.Serializable: একটি class implements Serializable লিখলে সে শুধু ঘোষণা করে “আমার object-কে byte-এ রূপান্তর করে ফাইলে বা নেটওয়ার্কে পাঠানো নিরাপদ।” Java-র serialization ব্যবস্থা এই চিহ্ন দেখে কাজ করে, না থাকলে NotSerializableException ছোড়ে। এমন interface-কে বলে marker interface; Cloneable আর RandomAccess-ও এর উদাহরণ। Java 5-এ annotation আসার পর নতুন “চিহ্ন” সাধারণত annotation দিয়ে দেওয়া হয় (পর্ব ৪৫), তবে marker interface-এর একটি সুবিধা থেকে যায় — সে একটি টাইপ, তাই compiler parameter-এ সেটা যাচাই করতে পারে। Serialization-এর বিস্তারিত পর্ব ৩৯-এ।

Functional interface — একটি abstract method, তাই একটি lambda

যে interface-এ ঠিক একটি abstract method আছে (default আর static method যত খুশি থাকুক), তাকে বলে functional interface. Runnable (run()), Comparator (compare()), আর ওপরের MessageSender — সবাই তাই। এমন interface-এর object বানাতে পুরো class লেখার দরকার নেই, একটি lambda-ই যথেষ্ট:

MessageSender console = (to, text) -> {
    System.out.println(to + " <- " + text);
    return true;
};

Compiler জানে MessageSender-এ একটিই ফাঁকা ঘর, তাই lambda-টি সেই send-এর শরীর হয়ে যায়। Interface-এর ওপরে @FunctionalInterface লিখে রাখলে কেউ ভুল করে দ্বিতীয় abstract method যোগ করলে compiler আটকাবে। পুরো গল্প পর্ব ৩৪-এ।

JDK-তে প্রতিদিন যে interface-গুলো দেখবেন

প্রতিটি সারির শিক্ষা একই: JDK আপনার class চেনে না, চেনে চুক্তি। আপনি চুক্তি সই করলেই JDK-র বিশাল যন্ত্রপাতি আপনার class-এর জন্য কাজ শুরু করে — একেই interface-এর আসল শক্তি বলে। Iterable সই করুন, for-each পাবেন; AutoCloseable সই করুন, try-with-resources পাবেন।

৮ · abstract class না interface — কীভাবে বেছে নেবেন

Java 8-এর পর interface-এও শরীরসহ method রাখা যায়, তাই সীমারেখা কিছুটা ঝাপসা হয়েছে। তবু চারটি প্রশ্ন করলে প্রায় সবসময় উত্তর পরিষ্কার হয়ে যায়:

ব্যবহারিক নিয়ম: শুরু করুন interface দিয়ে। যদি দেখেন কয়েকটি implementation-এ একই field আর একই কোড বারবার আসছে, তখন তাদের মাঝে একটি abstract class বসান — interface-টা রেখেই। JDK নিজে ঠিক এটাই করে: List হলো interface (চুক্তি), AbstractList হলো abstract class (ভাগ করা কোড), আর ArrayList দুটিকেই কাজে লাগায়। বাইরের কোড সবসময় List-এর কথাই বলে। আর সম্ভাব্য implementation-গুলো যদি আপনি নিজে সীমিত করতে চান — যেমন “পেমেন্টের ফল শুধু সফল, ব্যর্থ অথবা অপেক্ষমাণ” — তার জন্য Java 17-এর sealed interface আছে, পর্ব ২৬-এ।

৯ · AI-এর যুগে — interface অলংকার না প্রয়োজন, সেটা আপনি ঠিক করুন

AI-কে “একটি user management system লিখে দাও” বললে প্রায়ই দেখবেন: IUserService interface আর তার একমাত্র implementation UserServiceImpl, IUserRepository আর UserRepositoryImpl — প্রতিটি class-এর পাশে একটি করে interface, যার দ্বিতীয় কোনো implementation নেই, আসার সম্ভাবনাও নেই। অনেক enterprise কোডবেস থেকে শেখা অভ্যাস। কোড চলে, কিন্তু ফাইল দ্বিগুণ, আর method খুঁজতে প্রতিবার একটি অতিরিক্ত লাফ।

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

• প্রতিটি interface-এর অন্তত দুটি বাস্তব বা পরিকল্পিত implementation (টেস্টের নকলসহ) বলতে পারি
• প্রতিটি abstract class-এ সত্যিই ভাগ করা field বা কোড আছে
• কোনো interface শুধু constant রাখার জন্য নেই
• ওপরের স্তরের class নিচের স্তরের concrete class-কে new করছে না, চুক্তি নিচ্ছে
• দুটি interface-এর একই default method থাকলে class নিজে override করেছে
• চুক্তির অর্থ (null চলবে কি না, ব্যর্থ হলে কী হবে) Javadoc-এ লেখা আছে