Jaki jest sens fakultatywnej klasy Guava

To naprawdę wygląda jak Maybe Wzór Monad z Haskell.

Powinieneś przeczytać: Wikipedia Monad (Programowanie funkcyjne):

Edit: W Java8 jest wbudowana opcja, która ma monadyczne operatory, takie jak flatMap. Jest to temat kontrowersyjny, ale wreszcie został wdrożony.

Zobacz http://www.nurkiewicz.com/2013/08/optional-in-java-8-cheat-sheet.html

public Optional<String> tryFindSimilar(String s)  //...

Optional<Optional<String>> bad = opt.map(this::tryFindSimilar);
Optional<String> similar =       opt.flatMap(this::tryFindSimilar);

Operator flatMap jest niezbędny do umożliwienia operacji monadycznych i pozwala na łatwe łączenie wywołań, które zwracają opcjonalne wyniki.

Pomyśl o tym, jeśli użyjesz operatora map 5 razy, skończysz z Optional<Optional<Optional<Optional<Optional<String>>>>>, podczas gdy użycie flatMap da ci Optional<String>

Ponieważ Java8 wolałbym nie używać opcji Guava, która jest mniej potężny.

Dobrym powodem, aby go używać jest to, że sprawia, że Twoje nulle są bardzo znaczące. Zamiast zwracać wartość null, która może oznaczać wiele rzeczy (np. Błąd, niepowodzenie, pusta itp.), Możesz umieścić' nazwę ' Do null. Spójrz na ten przykład:

Zdefiniujmy podstawowe POJO:

class PersonDetails {

String person;
String comments;

public PersonDetails(String person, String comments) {
    this.person = person;
    this.comments = comments;
}

public String getPerson() {
    return person;
}


public String getComments() {
    return comments;
}

}

Teraz skorzystajmy z tego prostego POJO:

public Optional<PersonDetails> getPersonDetailstWithOptional () {

  PersonDetails details = null; /*details of the person are empty but to the caller this is meaningless,
  lets make the return value more meaningful*/


    if (details == null) {
      //return an absent here, caller can check for absent to signify details are not present
        return Optional.absent();
    } else {
      //else return the details wrapped in a guava 'optional'
        return Optional.of(details);   
    }
}

Teraz unikamy używania null i wykonujemy nasze kontrole z opcjonalnym więc jego znaczenie

public void checkUsingOptional () {

    Optional<PersonDetails> details = getPersonDetailstWithOptional();

    /*below condition checks if persons details are present (notice we dont check if person details are null,
    we use something more meaningful. Guava optional forces this with the implementation)*/
    if (details.isPresent()) {

      PersonDetails details = details.get();

        // proceed with further processing
        logger.info(details);

    } else {
        // do nothing
        logger.info("object was null"); 
    }

    assertFalse(details.isPresent());
}

Tak więc w końcu jest to sposób, aby null znaczące i mniej niejednoznaczne.

Najważniejszą zaletą opcjonalnego jest to, że dodaje więcej szczegółów do Umowy między wykonawcą a wywołującym funkcji. Z tego powodu jest użyteczny zarówno dla parametrów, jak i typu return.

Jeśli sprawisz, że konwencja będzie zawsze mieć Optional dla możliwych obiektów null, dodasz więcej wyjaśnień do przypadków takich jak:

1. Optional<Integer> maxPrime(Optional<Integer> from, Optional<Integer> to)

   Umowa tutaj jasno określa, że istnieje szansa, że wynik nie zostanie zwrócony, ale pokazuje również, że będzie działał z from i to jako nieobecne.

2. Optional<Integer> maxPrime(Optional<Integer> from, Integer to)

   Umowa określa, że od jest opcjonalne, więc nieobecna wartość może mieć specjalne znaczenie, takie jak początek od 2. Mogę się spodziewać, że wartość null dla parametru to rzuci wyjątek.

Więc dobrą częścią używania opcjonalnego jest to, że umowa stała się zarówno opisowa (podobnie z @NotNull adnotacją), ale także formalna, ponieważ musisz napisać kod .get(), aby poradzić sobie z Optional.