Dlaczego warto korzystać z opcji Opcjonalne w Javie 8+ zamiast tradycyjnych sprawdzania wskaźnika zerowego?

Niedawno przenieśliśmy się na Javę 8. Teraz widzę aplikacje zalane Optionalobiektami.

Przed Java 8 (styl 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

Po Javie 8 (styl 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

Nie widzę żadnej wartości dodanej, Optional<Employee> employeeOptional = employeeService.getEmployee();gdy sama usługa zwraca opcjonalną:

Pochodząc z tła Java 6, widzę Styl 1 jako bardziej przejrzysty i z mniejszą liczbą linii kodu. Czy brakuje mi tutaj jakiejś realnej korzyści?

Skonsolidowane ze zrozumienia wszystkich odpowiedzi i dalszych badań na blogu

Styl 2 nie obsługuje Java 8, aby w pełni zobaczyć zalety. W ogóle nie chcesz if ... use. Zobacz przykłady Oracle . Korzystając z ich rad, otrzymujemy:

Styl 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

Lub dłuższy fragment

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

Jeśli używasz Optionaljako warstwy „zgodności” między starszym interfejsem API, który może nadal zwracać null, pomocne może być utworzenie (niepustej) Opcjonalnej na ostatnim etapie, aby mieć pewność , że coś masz. Np. Gdzie napisałeś:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

Zdecydowałbym się na:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

Chodzi o to, aby wiedzieć , że istnieje niezerowe pracownik usług , więc można owinąć się w sposób, który Optionalz Optional.of(). Następnie, gdy do tego zadzwonisz getEmployee(), możesz, ale nie musisz, zatrudnić pracownika. Ten pracownik może (lub być może nie musi) mieć dokumentu tożsamości. Następnie, jeśli skończyłeś z identyfikatorem, chcesz go wydrukować.

Nie ma potrzeby jawnego sprawdzania, czy w kodzie nie ma żadnych wartości null, obecności itp.

Posiadanie Optionaljednej wartości nie ma prawie żadnej wartości dodanej . Jak widzieliście, to po prostu zastępuje czek na nullczek na obecność.

Posiadanie takich rzeczy ma ogromną wartość dodaną Collection. Wszystkie metody przesyłania strumieniowego wprowadzone w celu zastąpienia pętli niskopoziomowych w starym stylu rozumieją Optionalrzeczy i robią to, co należy (nie przetwarzając ich lub ostatecznie zwracając inny zestaw Optional). Jeśli masz do czynienia z n przedmiotami częściej niż z pojedynczymi przedmiotami (i robi to 99% wszystkich realistycznych programów), ogromną poprawą jest wbudowane wsparcie dla opcjonalnie prezentowanych rzeczy. W idealnym przypadku nigdy nie musisz sprawdzać obecności null ani obecności.

Tak długo, jak używasz Optionalfantazyjnego interfejsu API isNotNull(), tak, nie znajdziesz żadnych różnic w samym sprawdzaniu null.

Rzeczy, których nie powinno się używać Optionaldo

OptionalBad Code ™ używa tylko do sprawdzenia obecności wartości:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

Co należy używać Optionaldo

Unikaj nieobecności wartości, tworząc ją w razie potrzeby, gdy używasz metod API zwracających wartość zerową:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

Lub, jeśli utworzenie nowego pracownika jest zbyt kosztowne:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

Ponadto, uświadamiając wszystkim, że twoje metody mogą nie zwrócić wartości (jeśli z jakiegokolwiek powodu nie możesz zwrócić wartości domyślnej jak wyżej):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

I na koniec, istnieją wszystkie podobne do strumieni metody, które zostały już wyjaśnione w innych odpowiedziach, chociaż tak naprawdę nie decydujesz się ich użyć, Optionalale korzystasz z Optionaldostarczonych przez kogoś innego.

Kluczową kwestią dla mnie w korzystaniu z Opcjonalnego jest wyjaśnienie, kiedy programista musi sprawdzić, czy funkcja zwraca wartość, czy nie.

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

Twoim głównym błędem jest to, że nadal myślisz w kategoriach proceduralnych. To nie jest krytyka ciebie jako osoby, to tylko spostrzeżenie. Myślenie bardziej funkcjonalnymi terminami wiąże się z czasem i praktyką, dlatego metody są prezentowane i wyglądają jak najbardziej oczywiste, poprawne rzeczy, do których można zadzwonić. Twoim drugorzędnym drobnym błędem jest utworzenie Opcjonalnej w ramach metody. Opcjonalny ma na celu pomóc udokumentować, że coś może, ale nie musi, zwrócić wartość. Możesz nic nie dostać.

Doprowadziło to do napisania doskonale czytelnego kodu, który wydaje się całkowicie rozsądny, ale uwiodły cię podłe, kuszące bliźniaczki, które dostały i są obecne.

Oczywiście szybko pojawia się pytanie „dlaczego są obecne i nawet się tam dostać?”

Wielu ludzi tutaj tęskni za tym, że isPresent () jest to, że nie jest to coś, co zostało stworzone dla nowego kodu napisanego przez ludzi w pełni zaangażowanych w to, jak cholernie przydatne są lambdas i którzy lubią funkcjonalność.

Daje nam jednak kilka (dwóch) dobrych, wspaniałych, uroczych (?) Korzyści:

• Ułatwia przejście starszego kodu w celu korzystania z nowych funkcji.
• Ułatwia krzywe uczenia Opcjonalne.

Pierwszy jest raczej prosty.

Wyobraź sobie, że masz interfejs API, który wyglądał tak:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

I miałeś klasę klasyczną, używając tego jako takiego (wypełnij puste pola):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

Na pewno wymyślony przykład. Ale bądźcie ze mną tutaj.

Java 8 została uruchomiona i staramy się wejść na pokład. Jedną z rzeczy, które robimy, jest zamiana naszego starego interfejsu na coś, co zwraca Opcjonalne. Dlaczego? Ponieważ, jak ktoś już wspominał łaskawie: eliminuje to zgadywanie, czy coś może być zerowe . Inni zwracali już na to uwagę. Ale teraz mamy problem. Wyobraźmy sobie, że mamy (przepraszam, gdy nacisnąłem Alt + F7 przy niewinnej metodzie), 46 miejsc, w których ta metoda jest wywoływana w dobrze przetestowanym starszym kodzie, który w przeciwnym razie świetnie sobie radzi. Teraz musisz zaktualizować je wszystkie.

TO jest, gdzie isPresent świeci.

Ponieważ teraz: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {wyrzuć nowy NoSuchSnickersException (); } else {Consumer.giveDiabetes (lastSnickers); }

staje się:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

Jest to prosta zmiana, którą możesz dać nowemu juniorowi: może zrobić coś pożytecznego, a jednocześnie będzie mógł eksplorować bazę kodów. win-win. W końcu coś podobnego do tego wzoru jest dość rozpowszechnione. A teraz nie musisz przepisywać kodu, aby używać lambd lub czegokolwiek. (W tym konkretnym przypadku byłoby to trywialne, ale zostawiam wymyślanie przykładów, w których byłoby to trudne dla czytelnika).

Zauważ, że oznacza to, że sposób, w jaki to zrobiłeś, jest zasadniczo sposobem radzenia sobie ze starszym kodem bez wykonywania kosztownych przeróbek. A co z nowym kodem?

W twoim przypadku, gdy chcesz po prostu coś wydrukować, po prostu zrobiłbyś:

snickersCounter.lastConsumedSnickers (). ifPresent (System.out :: println);

Co jest dość proste i całkowicie jasne. Problem, który powoli wypływa na powierzchnię, polega na tym, że istnieją przypadki użycia dla get () i isPresent (). Służą do mechanicznej modyfikacji istniejącego kodu w celu użycia nowszych typów bez zbytniego zastanawiania się nad tym. To, co robisz, jest zatem mylone na następujące sposoby:

• Wywołujesz metodę, która może zwrócić null. Prawidłowym pomysłem byłoby to, że metoda zwraca null.
• Używasz starszych metod bandaid, aby poradzić sobie z tym opcjonalnym, zamiast używać smacznych nowych metod, które zawierają wściekłość lambda.

Jeśli chcesz użyć Opcjonalnego jako prostej kontroli bezpieczeństwa zerowego, powinieneś to zrobić po prostu:

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

Oczywiście dobrze wyglądająca wersja tego wygląda następująco:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

Nawiasem mówiąc, chociaż nie jest to w żaden sposób wymagane, zalecam użycie nowej linii na operację, aby łatwiej było ją odczytać. Łatwy do odczytania i zrozumienia bije zwięzłość każdego dnia tygodnia.

Jest to oczywiście bardzo prosty przykład, w którym łatwo zrozumieć wszystko, co próbujemy zrobić. W życiu nie zawsze jest to takie proste. Ale zauważ, jak w tym przykładzie wyrażamy nasze intencje. Chcemy UZYSKAĆ ​​pracownika, UZYSKAĆ ​​jego identyfikator i, jeśli to możliwe, wydrukować go. To druga duża wygrana z Opcjonalnym. Pozwala nam tworzyć wyraźniejszy kod. Myślę też, że robienie rzeczy takich jak tworzenie metody, która robi mnóstwo rzeczy, aby można było nakarmić ją mapą, jest ogólnie dobrym pomysłem.

Nie widzę korzyści w stylu 2. Wciąż musisz zdawać sobie sprawę, że potrzebujesz kontroli zerowej, a teraz jest ona jeszcze większa, a więc mniej czytelna.

Lepszym stylem byłoby, gdyby pracownikServive.getEmployee () zwrócił Opcjonalne, a kod stałby się:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

W ten sposób nie możesz wywołaćemplemployeeServive.getEmployee (). GetId () i zauważysz, że powinieneś jakoś obsługiwać opcjonalne wartości. A jeśli w całej twojej bazie kodu metody nigdy nie zwracają wartości zerowej (lub prawie nigdy z dobrze znanymi wyjątkami dla twojej drużyny od tej reguły), zwiększy to bezpieczeństwo przeciwko NPE.

Myślę, że największą korzyścią jest to, że jeśli sygnatura metody zwraca an Employee, nie sprawdza się wartości null. Dzięki temu podpisowi wiesz, że powrót pracownika jest gwarantowany. Nie musisz zajmować się przypadkiem awarii. Opcjonalnie wiesz, że tak.

W kodzie, który widziałem, są kontrole zerowe, które nigdy nie zawiodą, ponieważ ludzie nie chcą przeszukiwać kodu w celu ustalenia, czy wartość zerowa jest możliwa, więc rzucają wszędzie kontrole zerowe. To sprawia, że ​​kod jest nieco wolniejszy, ale co ważniejsze, sprawia, że ​​kod jest znacznie głośniejszy.

Jednak aby to zadziałało, musisz konsekwentnie stosować ten wzorzec.

Moja odpowiedź brzmi: po prostu nie. Pomyśl przynajmniej dwa razy, czy to naprawdę poprawa.

Wyrażenie (wzięte z innej odpowiedzi) jak

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

wydaje się być właściwym funkcjonalnym sposobem radzenia sobie z pierwotnie zerowalnymi metodami zwracania. Wygląda ładnie, nigdy się nie rzuca i nigdy nie sprawia, że ​​myślisz o obsłudze „nieobecnej” sprawy.

Wygląda lepiej niż w starym stylu

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

co czyni oczywistym, że mogą istnieć elseklauzule.

Funkcjonalny styl

• wygląda zupełnie inaczej (i jest nieczytelny dla osób nieprzyzwyczajonych do tego)
• to debugowanie
• nie może być łatwo przedłużony do obsługi „nieobecnego” przypadku ( orElsenie zawsze jest wystarczający)
• wprowadza w błąd, ignorując przypadek „nieobecny”

W żadnym wypadku nie należy go stosować jako panaceum. Jeśli miałoby to uniwersalne zastosowanie, semantykę .operatora należy zastąpić semantyką ?.operatora , zapomnieć o NPE i wszystkie problemy zignorować.

Będąc wielkim fanem Javy, muszę powiedzieć, że styl funkcjonalny jest po prostu zamiennikiem tego stwierdzenia przez biednego człowieka Javy

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

dobrze znany z innych języków. Czy zgadzamy się, że to oświadczenie

• nie jest (naprawdę) funkcjonalny?
• jest bardzo podobny do kodu w starym stylu, o wiele prostszy?
• jest znacznie bardziej czytelny niż styl funkcjonalny?
• jest przyjazny dla debuggera?

Opcjonalna jest koncepcja (typ wyższego rzędu) pochodząca z programowania funkcjonalnego. Użycie go eliminuje zagnieżdżone sprawdzanie zerowania i ratuje cię przed piramidą zagłady.