Should Java 8 getters return optional type?

java

best-practices

functional-programming

null-safety

byNikita Barsukov·Oct 14, 2024

When to use Optional for Java getters:

Yes: When null is a valid domain interpretation, employ Optional – it raises an inherent flag for special handling.
No: If null signifies incorrect state akin to an application bug, continue with the plain raw type.

Quick takeaway:

Encapsulate in Optional only if null carries a valuable, deliberate semantic.

Here's an example:

public class UserProfile {
    private String email;

    public Optional<String> getEmail() {
        return Optional.ofNullable(email); // Null is not a bug, but a possible state.
    }
}

Remember: Optional nudges developers to recognize and correctly address a missing value scenario.

Guiding API design with Optional

Optional shouldn't be sprinkled over your codebase; its inclusion in an API should be a well-considered choice aimed at expressing semantics:

Adopt it when there's a cogent case for representing value absence explicitly, encouraging consumers to handle the situation appropriately.
Use it as a tool for designing public library methods where the return value might be missing, and a clear signal is beneficial.
Choose based on the achieved clarity of your API and the promises on behavior your method extends to its clients.

The intersection of Optional and ORM tools

Though Optional contributes to expressive APIs, it might pose problems with frameworks such as Hibernate:

Frameworks like Hibernate often mandate null checks and may not natively handle Optional.
Conventions with JPA entities might diverge if the getter returns Optional, whereas setters and fields follow traditional patterns.
You can leverage tools like Nullness Checker as a complementary strategy, outlining nullability rules rather than over-relying on Optional.

Riding the safety escalator with Optional

Optional enables developers to design resilient codebases by forcing proper handling of the null case:

Resort to methods like orElse, ifPresent, orElseThrow to manage the absence of value safely.
With ifPresent, the wrapped code is triggered only when the value is available, effectively acting as a guard clause.
Thanks to Java 10, we now have orElseThrow, a semantically rich alternative to the notorious Optional.get.

Note: Optional.get is like a lift missing a safety inspection – you never use it without being sure it won't plummet.

Containing collections in an Optional? Think twice!

Employing Optional for collection types is usually an overkill and leads to navigating a thicker syntax soup:

An empty collection aptly represents a no-element situation without the need for an Optional.
Wrapping collections in Optional frequently results in verbose and awkward code.
When in doubt, favor simplicity: return an empty collection over engaging Optional<List<T>>.

Optional: More than a null replacer

The birth of Optional in Java world is inline with the flavors of functional programming, but it's no universal fix for historical null reference issues:

Optional should ideally be part of broader functional programming contours, not miscast as a null reference stand-in.
When designing your APIs, explore offering dual getters – one returning Optional and another yielding the raw type.
Foster practices promoting explicit null handling even outside Optional landscape to create a stronger and resilient codebase.

Riding the best practices wave with Optional

To surf the wave of using Optional, make sure you seize onto the board of best practices:

Prefer the conventional wisdom and use Optional sparingly for class fields, method parameters, and constructors.
Design classes to lean towards non-nullable members – use Optional to communicate deliberate absences.
Gauge where Optional amplifies clarity and wields the ability to make the potential absence of a value unquestionable.
Understand the domino-effect of using Optional – take a strategic leap when the clarity and robustness outweigh the initial discomfort of refactor.

Navigating the needle’s eye: Clarity vs. Overuse

Ahoy, developers! Dodge the icebergs of Optional overuse, keeping the ship of clarity afloat:

Save Optional for contexts where it adds clarity like a lighthouse guiding the seafarers.
Ascertain whether Optional claustrophobically cramps your API; sometimes returning null or throwing an exception is like owning a roomy mansion.
Find the equilibrium – go for Optional where it illumines. Steer clear from substituting every null reference with Optional.