أنماط مضادة (anti-patterns) في Optional

Written Explanation

The rule behind the rules

The Javadoc says Optional is primarily intended for use as a method return type where "no result" is a real possibility and null would be error-prone. It also says a variable of type Optional should never itself be null. The advice on fields, parameters, and collections below is widely used design guidance that follows from that intent; the Javadoc does not list those cases one by one.

Anti-pattern 1: Optional as a field

class BadProfile {
    private Optional<String> nickname;   // don't
}

Why it is a problem:

• It adds an extra object to every instance, only to say "this may be missing". A plain field can say the same thing.
• The field itself can still be null. Nothing stops a constructor from storing null in it, and then every use of the field breaks.
• It makes the class awkward to build: every caller wraps and unwraps values.

Do this instead: keep the field as a plain String, document that it may be null, and expose it through a getter that returns Optional. The Optional is created on the way out, which is where it helps the caller.

class Profile {
    private final String nickname;                       // may be null
    Optional<String> nickname() { return Optional.ofNullable(nickname); }
}

Anti-pattern 2: Optional as a method parameter

void send(String to, Optional<Integer> priority)   // don't

The caller now has three ways to say "no priority": Optional.empty(), null, or an Optional containing something. The compiler accepts null for the Optional parameter without complaint, so the method gets a null where it expects a box. It also forces every caller to write Optional.of(...) around a plain number.

Do this instead: use overloads (two methods with the same name and different parameters), or accept a plain value.

void send(String to, Integer priority) { ... }
void send(String to) { send(to, 1); }               // default priority

Anti-pattern 3: Optional around a collection

Optional<List<Order>> findOrders(String customer)    // don't

A list already has a way to say "nothing": it is empty. An Optional<List<Order>> has two kinds of "nothing" (an empty box and a box with an empty list) and callers must handle both. Return List<Order> and use an empty list when nothing is found. The caller can loop over it, check isEmpty(), or stream it, with no unwrapping. The same applies to arrays and maps.

Anti-pattern 4: an unconditional get()

String nick = findNickname(5).get();                // don't

If the box is empty, get() throws NoSuchElementException: No value present. That is the same crash as before, just with a different name, and the compiler does not complain. This is the most common Optional mistake and the one the lab in this module is designed to remove.

Do this instead, depending on what "missing" means:

• orElse("default") or orElseGet(...) for a harmless default.
• orElseThrow(() -> new SomeException("clear message")) when it must exist.
• ifPresent(...) when you only want to act if it exists.

The no-argument orElseThrow() has the same behaviour as get() but its name says what will happen. The Javadoc recommends it over get().

Anti-pattern 5: isPresent() followed by get()

if (r.isPresent()) { return r.get().toUpperCase(); }
return "NOBODY";                                     // works, but wordy

This is safe as long as the check and the get() stay together, but it is longer than needed and it keeps a bare get() in the code. The chain r.map(String::toUpperCase).orElse("NOBODY") says the same in one line. The if form is reasonable when the present branch does something large, such as several statements, but in that case ifPresent or ifPresentOrElse with a lambda is often still tidier.

Anti-pattern 6: a null Optional

Optional<String> bad = null;                         // don't
return null;                                         // from a method returning Optional

This defeats the purpose: callers trust the box to exist and do not check it for null. Always use Optional.empty() for "nothing". The Javadoc says it directly.

Quick reference