Optional — null-এর নিরাপদ বিকল্প

১ · “উত্তর নেই” — null দিয়ে বললে কী হয়

একটি অনলাইন দোকানের কথা ভাবুন। গ্রাহক ফোন করে মোবাইল নম্বর বললেন, আর আপনার কোড সেই নম্বর দিয়ে গ্রাহক খোঁজে: Customer findByMobile(String mobile). নম্বরটি তালিকায় থাকলে উত্তর সহজ। কিন্তু না থাকলে? Java-র পুরোনো রীতি ছিল null ফেরত দেওয়া। সমস্যা হলো, method-এর ঘোষণা দেখে সেটা বোঝার কোনো উপায় নেই। Customer লেখা টাইপ কথা দেয় একজন গ্রাহকের, অথচ মাঝে মাঝে দেয় “কিছুই না”।

ধরুন যে ডেভেলপার এই method ডাকছেন, তিনি ব্যস্ত, অথবা ধরে নিয়েছেন নম্বর সবসময় থাকবে। তিনি ফল একটি ভ্যারিয়েবলে রাখলেন, সেটি আরেকটি method-এ পাঠালেন, সেখান থেকে একটি তালিকায় গেল। তিন দিন পর রিপোর্ট বানানোর সময় কোনো একটি লাইনে customer.name() ডাকা হলো আর প্রোগ্রাম থেমে গেল NullPointerException দিয়ে। stack trace দেখাচ্ছে রিপোর্টের কোড — অথচ আসল ভুল ঘটেছিল খোঁজার জায়গায়, যেখানে “না পাওয়া” কথাটি চুপচাপ null হয়ে গিয়েছিল। null-এর সবচেয়ে বড় দোষ এটাই: সমস্যা যেখানে তৈরি হয়, ফাটে সেখান থেকে অনেক দূরে।

এই সমস্যা পুরোনো আর বিখ্যাত। null reference-এর জনক Tony Hoare ১৯৬৫ সালে ALGOL W ভাষায় এটি যোগ করেছিলেন, আর ২০০৯ সালে একে বলেছেন তাঁর “billion-dollar mistake” (ভাবনার প্রশ্ন ১-এ বিস্তারিত)। পর্ব ১৫-এ দেখেছেন, reference ভ্যারিয়েবল যখন কোনো object দেখায় না, তখন তার মান null; আর পর্ব ২৯-এ দেখেছেন Java 14-এ আসা (Java 15 থেকে ডিফল্টে চালু) বিস্তারিত NPE বার্তা, যা অন্তত বলে দেয় কোন জিনিসটি null ছিল। কিন্তু সেই বার্তা আসে ব্যর্থ হওয়ার পরে. Optional-এর লক্ষ্য তার আগেই — compile করার সময়ই — ডাকার কোডকে মনে করিয়ে দেওয়া।

// পুরোনো রীতি — ঘোষণা দেখে বোঝার উপায় নেই
Customer findByMobile(String mobile)            → গ্রাহক, অথবা চুপচাপ null

// Optional — টাইপেই লেখা “না-ও থাকতে পারে”
Optional<Customer> findByMobile(String mobile)  → Optional[গ্রাহক] অথবা Optional.empty

String n = findByMobile(m).name();              ✗ compile হয় না — Optional-এ name() নেই
String n = findByMobile(m).map(Customer::name).orElse("অজানা");   ✓ সিদ্ধান্ত নিতে হলো

শেষ দুই লাইনেই আসল কৌশল। Optional<Customer> নিজে Customer নয়, তাই তার ওপর সরাসরি name() ডাকা যায় না — compiler থামিয়ে দেয়। মান বের করার প্রতিটি পথে আপনাকে একটি সিদ্ধান্ত লিখতে হয়: ডিফল্ট দেবেন, exception ছুড়বেন, নাকি কিছুই করবেন না। Optional এসেছে Java 8-এ (২০১৪), java.util package-এ, Stream API-র সাথে একই সময়ে — কারণ findFirst() বা max()-এর মতো stream-এর কাজগুলোরও “কিছুই পাওয়া গেল না” বলার একটি পরিষ্কার উপায় দরকার ছিল।

২ · Optional বানানো — of, ofNullable, empty

Optional-এর কোনো public constructor নেই। বানাতে হয় তিনটি static factory method দিয়ে, আর কোনটি বেছে নেবেন তা নির্ভর করে আপনি মানটি সম্পর্কে কতটা নিশ্চিত তার ওপর:

Optional.of-এ null দিলে কী হয়, যাচাই করা যাক:

import java.util.*;

class Main {
    public static void main(String[] args) {
        String mobile = null;
        Optional<String> m = Optional.of(mobile);
        System.out.println(m);
    }
}

Exception in thread "main" java.lang.NullPointerException
	at java.base/java.util.Objects.requireNonNull(Objects.java:233)
	at java.base/java.util.Optional.of(Optional.java:113)
	at Main.main(Main.java:6)

trace-এর ওপরের দুই লাইন দেখাচ্ছে, Optional.of ভেতরে Objects.requireNonNull ডাকে — পর্ব ২৯-এর সেই fail-fast হাতিয়ার। খেয়াল করুন, এখানে বার্তা নেই: helpful NPE বার্তা আসে শুধু JVM নিজে যখন null-এর ওপর কিছু করতে গিয়ে ব্যর্থ হয়; কোড নিজে throw করলে আসে না। এই আচরণটা আসলে উপকারী। of ব্যবহার করে আপনি ঘোষণা দিচ্ছেন “এখানে null আসার কথা নয়”; এলে bug, আর সেটা ধরা পড়ল ঠিক যেখানে ঘটেছে।

পুরোনো API, যেমন Map.get(), এখনো মান না পেলে null দেয়। সেখানে সেতু হলো ofNullable: Optional.ofNullable(settings.get("timeout")). আর নিজের method-এ যখন জানেন কিছু পাওয়া যায়নি, সরাসরি return Optional.empty(); লিখুন।

৩ · মান বের করা — get()-এর ফাঁদ আর orElseThrow()

Optional হাতে পেলে নতুনদের প্রথম প্রবৃত্তি হয় পুরোনো null-যাচাইয়ের মতো লেখা:

Optional<Customer> c = findByMobile(mobile);
if (c.isPresent()) {
    System.out.println("স্বাগতম, " + c.get().name());
} else {
    System.out.println("গ্রাহক নেই");
}

এটা কাজ করে, কিন্তু এটা আসলে if (c != null)-এর লম্বা রূপ — নতুন কিছু পাওয়া গেল না। isPresent() মান থাকলে true দেয়; Java 11 থেকে উল্টোটা isEmpty()-ও আছে। আর get() ভেতরের মান দেয় — কিন্তু মান না থাকলে exception ছোড়ে। নিচের তিন লাইনের প্রোগ্রামে কেউ যাচাই করতে ভুলে গেছেন:

import java.util.*;

class Main {
    public static void main(String[] args) {
        Optional<String> phone = Optional.empty();
        String p = phone.get();
        System.out.println(p);
    }
}

Exception in thread "main" java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.get(Optional.java:143)
	at Main.main(Main.java:6)

NoSuchElementException একটি unchecked exception, বার্তা No value present. অর্থাৎ যাচাই ছাড়া get() ডাকলে আমরা ঠিক null-এর সমস্যায় ফিরে গেলাম, শুধু exception-এর নাম বদলেছে। সমস্যা হলো নামটা: “get” শুনে মনে হয় নিরাপদে মান নেওয়া, অথচ এটি ব্যর্থ হতে পারে। Java-র নকশাকারীরা পরে নিজেরাই স্বীকার করেছেন যে এই নাম বিভ্রান্তিকর। তাই Java 10-এ এসেছে orElseThrow() — হুবহু একই কাজ, একই exception, কিন্তু নামেই লেখা “না থাকলে ছুড়ব”। Java 10 থেকে get()-এর Javadoc-ও বলে, এর পছন্দের বিকল্প orElseThrow().

if (c.isPresent()) {
    return c.get().name();
}
return "অজানা";

return c.map(Customer::name).orElse("অজানা");

// এই অর্ডার আমরাই এইমাত্র সেভ করেছি — না পাওয়া মানে bug
Order o = findOrder(id).orElseThrow();

৪ · ডিফল্ট মান — orElse, orElseGet আর orElseThrow(Supplier)

একটি অ্যাপের config ভাবুন: সেটিং থাকলে সেটি, না থাকলে একটি ডিফল্ট। Map.get null দেয়, তাই ofNullable দিয়ে সেতু বানিয়ে:

int timeout = Optional.ofNullable(config.get("timeout"))   // "45" অথবা null
                      .map(Integer::parseInt)               // 45 অথবা ফাঁকা
                      .orElse(30);                          // না থাকলে 30

config-এ "timeout" = "45" থাকলে ফল ৪৫; কোনো "retries" না থাকলে একই কোড ডিফল্ট দেয় (Java 21-এ চালিয়ে যাচাই করা)। Integer::parseInt হলো একটি method reference — পর্ব ৩৪-এ শেখা, s -> Integer.parseInt(s)-এর ছোট রূপ।

orElse বনাম orElseGet — ডিফল্টের হিসাব কখন চলে

দুটিই ডিফল্ট দেয়, কিন্তু একটি বড় পার্থক্য আছে যা ইন্টারভিউতে প্রায়ই জিজ্ঞেস করা হয়। orElse(value) একটি তৈরি মান নেয়। orElseGet(supplier) নেয় একটি Supplier — একটি lambda, যা দরকার হলে মান বানাবে। আর Java-তে method ডাকার আগে তার argument-এর হিসাব হয়ে যায়। তাই orElse(loadDefault()) লিখলে মান থাকুক বা না থাকুক, loadDefault() চলবেই। ধাপে ধাপে দেখুন:

1static String loadDefault() {2    System.out.println("(ডিফল্ট লোড হলো)");3    return "bn";4}5Optional<String> lang = findSetting("lang");6String a = lang.orElse(loadDefault());7String b = lang.orElseGet(() -> loadDefault());

সহজ নিয়ম: ডিফল্ট যদি আগে থেকে তৈরি একটি সস্তা মান হয় (30, "অজানা", একটি constant), orElse লিখুন — পড়তে সহজ। ডিফল্ট বানাতে যদি কোনো কাজ করতে হয় — নতুন object, method ডাকা, নেটওয়ার্ক, ডেটাবেস — orElseGet. আর বিশেষ সাবধান: ডিফল্টের কোডে যদি কোনো side effect থাকে (লগ লেখা, ডেটাবেসে নতুন সারি তৈরি), orElse দিলে সেটা প্রতিবার ঘটবে — মান থাকলেও।

orElseThrow(Supplier) — নিজের exception

কুপন কোডের কথা ভাবুন। ব্যবহারকারী একটি কোড লিখলেন, আর সেটি বৈধ নাও হতে পারে। খোঁজার method Optional<Coupon> দেয়, কারণ “এই কোড নেই” স্বাভাবিক ফল। কিন্তু অর্ডার নিশ্চিত করার স্তরে এসে অবৈধ কুপন মানে প্রক্রিয়া থামানো, আর ব্যবহারকারীকে স্পষ্ট বার্তা দেখানো:

Coupon c = findCoupon(code)
        .orElseThrow(() -> new IllegalArgumentException("কুপন বৈধ নয়: " + code));

এখানেও Supplier — exception object তৈরি হয় শুধু মান না থাকলে। (পর্ব ২৯-এর আলোচনা মনে করুন: exception বানানো সস্তা নয়, কারণ stack trace রেকর্ড হয়।) কোনো argument ছাড়া orElseThrow() দেয় NoSuchElementException; নিজের exception দিতে চাইলে এই রূপ।

৫ · map আর filter — বাক্স না খুলেই কাজ

এবার Optional-এর সবচেয়ে শক্তিশালী অংশ। গ্রাহকের ঠিকানা থাকতে পারে, না-ও পারে; ঠিকানা থাকলেও জেলা লেখা না-ও থাকতে পারে। পুরোনো রীতিতে জেলা বের করতে লিখতে হতো সিঁড়ির মতো null-যাচাই:

String district = "জেলা অজানা";
Customer c = findByMobileOld(mobile);          // null দিতে পারে
if (c != null) {
    Address a = c.address();
    if (a != null) {
        String d = a.district();
        if (d != null) district = d;
    }
}

আসল কথা একটাই — “গ্রাহক → ঠিকানা → জেলা, কোথাও না পেলে ‘জেলা অজানা’” — কিন্তু চোখে পড়ে শুধু if. একটি যাচাই বাদ পড়লেই NPE. Optional দিয়ে একই কথা:

String district = findByMobile(mobile)        // Optional<Customer>
        .map(Customer::address)               // Optional<Address>
        .map(Address::district)               // Optional<String>
        .orElse("জেলা অজানা");

map(f)-এর নিয়ম দুই লাইনের: মান থাকলে f চালাও আর ফলটি নতুন Optional-এ রাখো; মান না থাকলে f চালিয়োই না, ফাঁকাটিই এগিয়ে দাও। আরও একটি সূক্ষ্ম কথা: f যদি null ফেরত দেয়, map সেটাকে ফাঁকা Optional বানিয়ে দেয় (ভেতরে ofNullable). তাই যে record-এর accessor null দিতে পারে, তার ওপরও চেইন নিরাপদ। ধাপে ধাপে দেখুন — প্রথমে একজন গ্রাহক যাঁর ঠিকানায় জেলা লেখা নেই, তারপর একটি অচেনা নম্বর:

1Optional<Customer> c = findByMobile(m);2Optional<Address>  a = c.map(Customer::address);3Optional<String>   d = a.map(Address::district);4String r = d.orElse("জেলা অজানা");

এবার পুরোটা চালিয়ে দেখুন। তিনজন গ্রাহক: রহিমের পুরো ঠিকানা আছে, করিমের ঠিকানায় জেলা নেই, সুমির ঠিকানাই নেই; আর একটি অচেনা নম্বর। খোঁজার কাজটি পর্ব ৩৫-এর Stream দিয়ে — findFirst() নিজেই Optional দেয়:

import java.util.*;

record Address(String street, String district) {}
record Customer(String name, String mobile, Address address) {}
class Main {
    static final List<Customer> CUSTOMERS = List.of(
        new Customer("রহিম", "01711000001", new Address("মিরপুর ১০", "ঢাকা")),
        new Customer("করিম", "01811000002", new Address("নিউ মার্কেট", null)),
        new Customer("সুমি", "01911000003", null));
    static Optional<Customer> findByMobile(String mobile) {
        return CUSTOMERS.stream().filter(c -> c.mobile().equals(mobile)).findFirst();
    }
    static String districtOf(String mobile) {
        return findByMobile(mobile).map(Customer::address)
            .map(Address::district)
            .orElse("জেলা অজানা");
    }
    public static void main(String[] args) {
        System.out.println(findByMobile("01711000001").map(Customer::name).orElse("নেই"));
        System.out.println(findByMobile("01500000000"));
        for (String m : List.of("01711000001", "01811000002", "01911000003", "01500000000"))
            System.out.println(m + " → " + districtOf(m));
    }
}

filter — শর্ত না মিললে ফাঁকা

filter(শর্ত) মান থাকলে শর্ত যাচাই করে: মিললে Optional যেমন ছিল তেমন, না মিললে ফাঁকা। ধরুন কুপন পাওয়া গেছে, কিন্তু মেয়াদ শেষ হলে সেটা না-পাওয়ার মতোই:

int percent = findCoupon(code)
        .filter(Coupon::isActive)       // মেয়াদ শেষ হলে ফাঁকা
        .map(Coupon::percent)
        .orElse(0);                     // কোনো ছাড় নেই

Optional.of(5).filter(n -> n > 10) ছাপলে আসে Optional.empty. Stream-এর map/filter-এর সাথে মিলটা লক্ষ করুন — Optional-কে ভাবতে পারেন সর্বোচ্চ একটি উপাদানের stream হিসেবে।

৬ · flatMap — বাক্সের ভেতরে বাক্স হলে

অনেক সময় চেইনের মাঝের method নিজেই Optional দেয়। ধরুন ঠিকানা আলাদা একটি সার্ভিস থেকে আসে, আর সেটা না-ও থাকতে পারে: Optional<Address> addressOf(User u). এখন যদি map দিয়ে লেখেন:

import java.util.*;

record Address(String district) {}
record User(String name) {}

class Main {
    static Optional<User> findUser(String phone) { return Optional.of(new User("রহিম")); }
    static Optional<Address> addressOf(User u) { return Optional.empty(); }
    public static void main(String[] args) {
        Optional<Address> a = findUser("017").map(Main::addressOf);
        System.out.println(a);
    }
}

Main.java:10: error: incompatible types: inference variable U has incompatible bounds
        Optional<Address> a = findUser("017").map(Main::addressOf);
                                                 ^
    equality constraints: Address
    lower bounds: Optional<Address>
  where U,T are type-variables:
    U extends Object declared in method <U>map(Function<? super T,? extends U>)
    T extends Object declared in class Optional
1 error

বার্তাটি ভয়ের মতো দেখালেও কথা সহজ। map function-এর ফলকে নতুন বাক্সে ভরে। function নিজেই বাক্স (Optional<Address>) দিচ্ছে, তাই ফল দাঁড়ায় Optional<Optional<Address>> — বাক্সের ভেতরে বাক্স। আপনি চেয়েছিলেন Optional<Address>; compiler বলছে “U-কে Address হতে হবে (equality), অথচ পাচ্ছি Optional<Address> (lower bound)”. সমাধান flatMap: সে function-এর দেওয়া বাক্সটিই সরাসরি ফেরত দেয়, নতুন করে মোড়ে না।

findUser("017")
→ Optional[User[name=রহিম]]
টাইপ: Optional<User>

Optional<Address> addressOf(User u)
ঠিকানার সার্ভিসে তথ্য না-ও থাকতে পারে
তাই এর ফেরত-টাইপও Optional — ঠিক কাজ

.map(Main::addressOf)
→ Optional[Optional.empty]
টাইপ: Optional<Optional<Address>>
বাইরের বাক্স ভরা, ভেতরেরটা ফাঁকা — বিভ্রান্তিকর

.flatMap(Main::addressOf)
→ Optional.empty
টাইপ: Optional<Address>
user না থাকলেও ফাঁকা, ঠিকানা না থাকলেও ফাঁকা

findUser(p)
    .flatMap(Main::addressOf)
    .map(Address::district)
    .orElse("জেলা অজানা")

Stream-এর flatMap-ও একই চিন্তা: প্রতিটি উপাদান থেকে একটি stream বানিয়ে সব stream-কে এক stream-এ চ্যাপ্টা করা (পর্ব ৩৫)। গণিত আর functional programming-এর ভাষায় এই ধরনের “বাক্স + flatMap” কাঠামোকে বলে monad — নামটা মনে রাখার দরকার নেই, তবে ভাবনার প্রশ্ন ২-এ এর ইতিহাস আছে।

৭ · মান ব্যবহার করা, আর Stream-এর সাথে Optional

সবসময় মান বের করে আনতে হবে এমন নয়। অনেক সময় শুধু “থাকলে কিছু করো” — যেমন গ্রাহক পাওয়া গেলে তাঁকে SMS পাঠানো:

findByMobile(m).ifPresent(c -> sms.send(c.mobile(), "আপনার অর্ডার পাঠানো হয়েছে"));

findByMobile(m).ifPresentOrElse(                       // Java 9
        c -> System.out.println("স্বাগতম, " + c.name()),
        () -> System.out.println("নতুন গ্রাহক — নিবন্ধন করুন"));

Optional<Customer> c = findInCache(m).or(() -> findInDatabase(m));   // Java 9

• ifPresent(action) — মান থাকলে action চালায়, না থাকলে কিছুই না (Java 8).
• ifPresentOrElse(action, emptyAction) — দুই পথই এক জায়গায় (Java 9). isPresent/get/else-এর পরিষ্কার বিকল্প।
• or(supplier) — ফাঁকা হলে আরেকটি Optional থেকে চেষ্টা (Java 9). ক্যাশে না পেলে ডেটাবেসে খোঁজা — আর supplier হওয়ায় ক্যাশে পেলে ডেটাবেস ডাকাই হয় না। orElseGet দেয় সাধারণ মান, or দেয় Optional — এটুকুই পার্থক্য।
• stream() — মান থাকলে এক উপাদানের stream, না থাকলে ফাঁকা stream (Java 9). এর আসল ব্যবহার নিচে।

JDK-র কোথায় কোথায় Optional

নিজে না বানালেও Optional প্রতিদিন হাতে আসবে, কারণ Stream API-র যে কাজগুলোর উত্তর না-ও থাকতে পারে, সবগুলো Optional দেয়:

শেষ সারিটি বাস্তবে খুব কাজের। একজন শিক্ষার্থীর নম্বরের তালিকা ফাঁকা হলে গড় কত? ০ বললে ভুল তথ্য দেওয়া হয় — মনে হয় তিনি সব বিষয়ে শূন্য পেয়েছেন। তাই Java ফাঁকা stream-এর গড়ে দেয় OptionalDouble.empty, আর সিদ্ধান্ত আপনার। OptionalInt, OptionalLong আর OptionalDouble আলাদা class, কারণ Optional<Integer> হলে প্রতিটি সংখ্যা আগে autoboxing-এ Integer object হতো, তারপর আবার Optional-এ মোড়া হতো — দুইবার মোড়ানো। এদের method-এর নাম একটু আলাদা: getAsInt(), getAsDouble(); আর এদের map/flatMap/filter নেই।

Optional-এর stream — ফাঁকাগুলো বাদ দিয়ে মানগুলো রাখা

ধরুন একটি ঈদ অফারে ব্যবহারকারীরা চারটি কুপন কোড জমা দিয়েছেন, যার কিছু অবৈধ। প্রতিটি কোডের জন্য discount(code) দেয় Optional<Integer>. আপনি চান শুধু বৈধ ছাড়গুলোর একটি তালিকা। map করলে পাবেন Stream<Optional<Integer>> — আবার বাক্সে মোড়া উপাদান। Java 9-এর Optional::stream দিয়ে flatMap করলে প্রতিটি ভরা Optional হয় এক উপাদানের stream, প্রতিটি ফাঁকা হয় শূন্য উপাদানের stream, আর সব মিলে একটি সমতল stream:

1List<Integer> valid = Stream.of("EID10", "FAKE", "PUJA15", "")2    .map(Main::discount)          // Stream<Optional<Integer>>3    .flatMap(Optional::stream)    // Stream<Integer>4    .toList();

এবার এই পর্বের তিনটি আচরণ একসাথে প্রমাণ করুন — orElse বনাম orElseGet, Optional::stream, আর ফাঁকা নম্বর-তালিকার গড়:

import java.util.*;
import java.util.stream.*;

class Main {
    static String loadDefault() {
        System.out.println("  (ডিফল্ট ভাষা লোড হলো)");
        return "bn";
    }
    static final Map<String, Integer> COUPONS = Map.of("EID10", 10, "PUJA15", 15);
    static Optional<Integer> discount(String code) {
        return Optional.ofNullable(COUPONS.get(code));     // Map.get null দেয়
    }
    public static void main(String[] args) {
        Optional<String> lang = Optional.of("en");
        System.out.println("orElse: " + lang.orElse(loadDefault()));
        System.out.println("orElseGet: " + lang.orElseGet(Main::loadDefault));
        List<Integer> valid = Stream.of("EID10", "FAKE", "PUJA15", "")
            .map(Main::discount).flatMap(Optional::stream).toList();
        System.out.println("বৈধ ছাড়: " + valid);
        List<Integer> marks = List.of();
        OptionalDouble avg = marks.stream().mapToInt(Integer::intValue).average();
        System.out.println(avg + " → " + avg.orElse(0.0));
        System.out.println(IntStream.of(70, 80, 90).average());
    }
}

৮ · সঠিক ব্যবহার — কোথায় Optional, কোথায় নয়

Optional নিয়ে সবচেয়ে বেশি ভুল হয় “কোথায়” ব্যবহার করবেন তা নিয়ে। Java-র ভাষা-স্থপতি Brian Goetz নিজে Stack Overflow-তে লিখেছেন: Optional-এর উদ্দেশ্য ছিল লাইব্রেরির method-এর ফেরত-টাইপে “কোনো ফল নেই” বোঝানোর একটি সীমিত ব্যবস্থা, যেখানে null ব্যবহার করলে ভুল হওয়ার সম্ভাবনা খুব বেশি। এটি সব null-এর সাধারণ বদলি হিসেবে বানানো হয়নি। Oracle-এর JDK দলের Stuart Marks তাঁর বক্তৃতাগুলোতে এই নির্দেশনাকে কয়েকটি নিয়মে সাজিয়েছেন। মূল কথাগুলো:

আরও কয়েকটি নিয়ম, যা অভিজ্ঞ Java ডেভেলপাররা মেনে চলেন:

• Optional ভ্যারিয়েবল বা ফেরত-মান কখনো null নয়। ফাঁকা বোঝাতে সবসময় Optional.empty().
• শুধু একটি if এড়াতে Optional বানাবেন না। Optional.ofNullable(name).orElse("অতিথি") লেখার চেয়ে name != null ? name : "অতিথি" বা Objects.requireNonNullElse(name, "অতিথি") (Java 9) সহজ — Optional শুধু চেইন বানাতে তৈরি করা অপচয়।
• চেইনের ভেতরে আরেকটি Optional চেইন, বা কোথাও Optional<Optional<T>> দেখলে কোড সম্ভবত বেশি জটিল হয়ে গেছে — ভেঙে ছোট method বানান।
• Optional-এ == বা synchronized নয়। Javadoc একে value-based class বলে: দুটি Optional তুলনা করুন equals দিয়ে, কারণ একই মানের দুটি Optional একই object হবে কি না তার নিশ্চয়তা নেই।

খরচ কতটা?

প্রতিটি ভরা Optional একটি ছোট object — heap-এ জায়গা, garbage collector-এর কাজ। একটি method প্রতি সেকেন্ডে কয়েক লাখবার ডাকা হলে এটা চোখে পড়তে পারে। JIT compiler অনেক সময় escape analysis দিয়ে এই object পুরোপুরি বাদ দিতে পারে, যখন সেটি method-এর বাইরে যায় না — তবে সেটা নিশ্চিত নয়। বাস্তব নিয়ম: সাধারণ ব্যবসার কোডে এই খরচ নগণ্য, পরিষ্কারতার লাভ অনেক বড়; খুব গরম লুপে বা বিশাল array-এর প্রতিটি উপাদানে Optional রাখার আগে মেপে দেখুন। ফাঁকা Optional-এর জন্য নতুন object লাগে না — বর্তমান JDK-তে Optional.empty() একটিই ভাগ করা ফাঁকা object দেয় (তবে == দিয়ে এর ওপর নির্ভর করবেন না)।

Optional ছাড়াও “না থাকা” বোঝানোর পথ

শেষ সারিটি নিয়ে একটু বলা দরকার। বহু বছর ধরে বিভিন্ন লাইব্রেরি নিজেদের @Nullable annotation বানিয়েছে — JetBrains, Android, Spring, FindBugs — প্রত্যেকের অর্থ একটু আলাদা। JSpecify নামে একটি যৌথ উদ্যোগ (Google, JetBrains সহ বেশ কয়েকটি প্রতিষ্ঠান) এগুলোর একটি অভিন্ন মান তৈরি করেছে — এর 1.0 সংস্করণ প্রকাশিত হয় ২০২৪ সালে। এই annotation compiler নিজে যাচাই করে না; IDE বা বাড়তি টুল (যেমন NullAway) তা পড়ে সতর্ক করে। Optional-এর সাথে এর বিরোধ নেই: Optional ফেরত-টাইপে, annotation field আর parameter-এ।

৯ · AI-এর যুগে — Optional-এর কোড রিভিউ করুন

AI-কে “null-safe করে লেখো” বললে প্রায়ই দেখবেন কোড ভরে গেছে Optional দিয়ে — কিন্তু ভুল জায়গায়। AI শিখেছে ইন্টারনেটের অসংখ্য উদাহরণ থেকে, যার বড় অংশ Java 8-এর শুরুর দিকের, যখন সবাই Optional নতুন শিখছিলেন। তাই isPresent()-get() জোড়া, Optional field, আর orElse(repository.findDefault())-এর মতো কোড খুব সাধারণ। compile হয়, demo-তে চলে — সমস্যা লুকিয়ে থাকে।

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

• কোনো isPresent() + get() জোড়া নেই; get() থাকলে কেন নিরাপদ তা স্পষ্ট
• কোনো field, constructor/method parameter বা collection-এর উপাদান Optional নয়
• Optional-ফেরত method-এ কোথাও return null নেই
• orElse(...)-এর ভেতরে কোনো method ডাক, new বা side effect নেই — থাকলে orElseGet
• Optional দেয় এমন method-এর ওপর map নয়, flatMap; কোথাও Optional<Optional<...>> নেই
• অনেক ফলের জন্য ফাঁকা collection, Optional নয়
• শুধু একটি if এড়াতে Optional বানানো হয়নি